A community effort to collect a curated set of analysis pipelines built using Nextflow.

nf-core

image.png

Did anyone observe that a pipeline only caches part of the results even though they are all the same process?
I know from my previous ran that all processes (only vcf2counts not) finished for all samples and now that I had to `-resume` only part of it was cached?

Oh, we've seen that internally actually, but we haven't figured out why yet :face_with_raised_eyebrow:

Yes, I see this all the time, and sometimes I see it completely restart a particular step even though it and several downstream passed a resume before

Were some of the tasks retried in the initial run? I only recently learned that you can't delete empty folders in the work directory after `nextflow clean`, as that will break the caching.

The only time I've seen that is from implicit merging of channels, i.e. a process taking two queue type channels, but I'm guessing that has been ruled out already.

I mean it works partially so I thought its more infrastructure than code?

Try using the lineage information to see if that sheds any light on it: <https://docs.seqera.io/nextflow/tutorials/data-lineage#compare-task-runs>
Otherwise we should try and get this reopened: <https://github.com/nextflow-io/nextflow/issues/4894>

what does the log say, <@U065DAZ0PL5>? Of both the original and resumed run?

I am not sure what to look for honestly :sweat_smile:

Yeah this is a very good reason to enable lineage globally for Nextflow, so that you can retrospectively look at cache calculations in these cases 

Related: <https://feedback.seqera.io/feature-requests/p/display-task-hash-calculation-inputs-in-platform|https://feedback.seqera.io/feature-requests/p/display-task-hash-calculation-inputs-in-platform> (been discussing this internally just recently)

I agree with <@UNMC49PJS> that this "partial" cache failure can be due to non-deterministic ordering of channel inputs. Even cached runs still go through the motions of pretending to run processes, so things can come out in a different order each time. Depending on workflow logic, this can subtly alter inputs

One thing that caught me out was using `.first()` on channels which then every so often gave a different first file, breaking caching.

This is the pipeline i am using: <https://github.com/qbic-pipelines/vcftocounts> if you spot anything I will try and fix it