Description of the bug

I think the same underlying issue reported here also affects the FASTQ_PREPROCESS_GATK worfklow in Sarek v3.7.1, not just Parabricks.

I’m seeing silent failures with multi-lane samples where:

• Single-lane samples publish outputs correctly
• Multi-lane samples run fastq preprocessing (and fgbio when enabled), produce files in work/, but nothing is published
• Nextflow reports successful completion with no errors

This appears to be the same output binding issue addressed here: fastqs are grouped by meta.id, but downstream steps assume a single fastq pair per sample, so output filenames don’t match declared outputs and are silently dropped.

This is reproducible in v3.7.1 using a samplesheet with mixed single and multi-lane samples. Would it make sense to apply the same fix logic to subworkflows/local/fastq_preprocess_gatk/main.nf as well? Thanks!

Command used and terminal output

Relevant files

No response

System information

No response