Has anyone else ran into errors such as the one below? I'm getting it with sarek v.

3.6.1

when running it with

--save_output_as_bam

. The pipeline ran fine a couple of days ago without this parameter. I also remember running into this issue a while before and I think I got rid of it by disabling FASTQ splitting with

--split_fastq 0

. This is the error message:

Detected join operation duplicate emission on left channel -- offending element: key=[patient:CALF, sample:CALF, sex:NA, status:0, n_fastq:16, data_type:cram, id:CALF, num_intervals:16]; value=/mnt/beegfs/simona-marc-bos/work/bb/c8b1bac594ec9a7a39c0ddf2f30f70/CALF_3_1-121005158.recal.bam

The sample sheet itself is fine, there aren't any duplicate IDs in there.

I had something similar (don't remember if exactly the same, and I deleted it), because I use the same sample name by accident for both tumor and normal sample. If you run the pipeline with just that one sample, do you still get that error? You could post the

.nextflow.log

, maybe the developers can see something. If you are rerunning it, maybe

-dump-channels

is instructive ...

I don't have the

.nextflow.log

anymore, but I had a look in it and there really wasn't anything else of use besides the error message that I've previously posted, which was followed by a stack trace. Weird thing is, that running the analysis with

--split_fastq 0

also resulted in a similar error, but a different sample was mentioned this time. I'm pretty sure that my sample sheet is fine (I'm running joint germline variant calling), and the problem is with how the channels are mixing up during the recalibration phased, when the outputs need to be saved as BAM. I am re-running the whole thing again, downgrading the pipeline from

3.6.1

to

3.5.1

. I remember things working better for me with this version, for whatever reason.

Hmm, possible that there is a bug in the newer version, I guess your test should show. That you get different samples failing in different run is not necessarily surprising, since the order in which the samples are processes is not deterministic, and the first to fail will kill the pipeline. This could be either because of a pipeline bug or something in the sample sheet that affects all samples.

I had a deeper look at this and opened an issue report on GitHub: https://github.com/nf-core/sarek/issues/2064

Thanks for testing and reporting. It is definitely strange that it only happens with converted BAMs ...