Seqkit_pair unknown recognition error type: groovyjarjarantlr4.v4.runtime.LexerNoViableAltException

Have you checked the docs?

• nf-core website: troubleshooting
• nf-core modules documentation

Description of the bug

Problem

Pipeline launch produced two identical warnings to stderr:

unknown recognition error type: groovyjarjarantlr4.v4.runtime.LexerNoViableAltException
unknown recognition error type: groovyjarjarantlr4.v4.runtime.LexerNoViableAltException

The warnings were non-fatal — the pipeline ran successfully — but they cluttered output and raised concerns about code correctness.

Location

File: modules/nf-core/seqkit/pair/main.nf, line 33

find . -maxdepth 1 -name "*.fastq" -exec gzip {} \;

Root Cause

The \; sequence sits inside a Groovy triple-double-quoted GString ("""..."""). Groovy's ANTLR4-based lexer only recognizes specific escape sequences in GStrings: \n, \t, \r, \b, \f, \\, \", \', \$, \uXXXX, and octal escapes. The semicolon is not in that set, so \; is an invalid escape sequence.

When the lexer encounters \;, it cannot match any token rule and throws a LexerNoViableAltException. ANTLR4 recovers and continues parsing (which is why the pipeline still runs), but the recovery emits the "unknown recognition error type" warning to stderr.

Two warnings appear because Nextflow parses the config and script files in two passes during startup (profile resolution and script compilation), triggering the same lexer error each time.

This is a known Nextflow/Groovy issue documented in:

• nextflow-io/nextflow#5832
• nextflow-io/nextflow#2680 (originally filed against CDCgov/mycosnp-nf)

Fix

Changed \; to \\; so Groovy interprets the double backslash as a literal backslash character, correctly passing \; to bash at runtime:

- find . -maxdepth 1 -name "*.fastq" -exec gzip {} \;
+ find . -maxdepth 1 -name "*.fastq" -exec gzip {} \\;

This is consistent with all other backslash usages in the pipeline's GString script blocks (e.g., \\t, \\n, \\$), where backslashes intended for bash are always double-escaped.

Command used and terminal output

Relevant files

System information

Nextflow Version: 25.04.6
Executor: awsbatch
Seqkit_pair sha: 41dfa3f7c0ffabb96a6a813fe321c6d1cc5b6e46

Read modules/nf-core/seqkit/pair/main.nf at line 33 and compare its backslash escaping with the other GString script usages in the module. Verify the module or pipeline launches without the repeated LexerNoViableAltException warnings; the reported fix provides the expected escaped command form.