Description of the bug
When a run fails/is killed, and then resumed, sometimes endorspy is not ran at all, leading to endogenous information missing from the multiqc report.
Steps to reproduce
Start any run that includes endorspy, and kill the job before resuming the run. Even if endorspy has already run, it will not be picked up in the resumed run and will not appear in the multiqc report.
Expected behaviour
endorspy processes are cached normally and included in the output.
Log files
Have you provided the following extra information/files:
System
- Hardware:
- Executor:
- OS:
- Version
Nextflow Installation
Container engine
- Engine: singularity
- version: 3.7.1
- Image tag: nfcore/eager:2.4.2
Additional context
The current output of the endorspy process is a tuple instead of a file channel. I have a feeling that might be causing the behaviour.
|
tuple samplename, libraryid, lane, seqtype, organism, strandedness, udg, path("*.json") into ch_endorspy_for_multiqc |
The MQC output channel of another process for comparison:
|
path "*_fastqc.{zip,html}" into ch_prefastqc_for_multiqc |
In general, multiqc input channels are file channels, but there are cases where they are actually tuple channels. this should be fixed throughout.
Description of the bug
When a run fails/is killed, and then resumed, sometimes
endorspyis not ran at all, leading to endogenous information missing from the multiqc report.Steps to reproduce
Start any run that includes endorspy, and kill the job before resuming the run. Even if endorspy has already run, it will not be picked up in the resumed run and will not appear in the multiqc report.
Expected behaviour
endorspy processes are cached normally and included in the output.
Log files
Have you provided the following extra information/files:
.nextflow.logfileSystem
Nextflow Installation
Container engine
Additional context
The current output of the endorspy process is a tuple instead of a file channel. I have a feeling that might be causing the behaviour.
eager/main.nf
Line 1812 in 43a239b
The MQC output channel of another process for comparison:
eager/main.nf
Line 691 in 43a239b
In general, multiqc input channels are file channels, but there are cases where they are actually tuple channels. this should be fixed throughout.