Bug report
Expected behavior and actual behavior
In the Nextflow documentation realtime is described as
**realtime**
Task execution time i.e. delta between completion and start timestamp.
I found that this is often not true and quite by a lot. See the following raw trace:
submit duration realtime start complete
1774271746328 16901 8000 1774271746424 1774271763229
1774271763256 35975 6000 1774271766533 1774271799231
Now you can subtract complete - start.
For the first line this is 1774271763229 - 1774271746424 = 16805. This does not correspond to realtime given at 8000 or exactly 8s.
While the correct value is initially set
|
record.realtime = completeTimeMillis - startTimeMillis |
it is replaced a few lines later
|
if(file) record.parseTraceFile(file) |
by this value
Steps to reproduce the problem
Run nextflow run nf-core/demo -r 1.1.0 -profile test,docker and look at the execution_trace_<timestamp>.txt file's realtime vs complete - start value.
Environment
- Nextflow version: 25.10.4
Either the documentation is wrong and should be changed or the value should not be overwritten / a new walltime parameter introduced.
Bug report
Expected behavior and actual behavior
In the Nextflow documentation
realtimeis described asI found that this is often not true and quite by a lot. See the following raw trace:
Now you can subtract
complete-start.For the first line this is
1774271763229 - 1774271746424 = 16805. This does not correspond torealtimegiven at8000or exactly8s.While the correct value is initially set
nextflow/modules/nextflow/src/main/groovy/nextflow/processor/TaskHandler.groovy
Line 239 in 00f35b3
it is replaced a few lines later
nextflow/modules/nextflow/src/main/groovy/nextflow/processor/TaskHandler.groovy
Line 246 in 00f35b3
by this value
nextflow/modules/nextflow/src/main/resources/nextflow/executor/command-trace.txt
Line 206 in 9d65b9e
Steps to reproduce the problem
Run
nextflow run nf-core/demo -r 1.1.0 -profile test,dockerand look at theexecution_trace_<timestamp>.txtfile'srealtimevscomplete - startvalue.Environment
Either the documentation is wrong and should be changed or the value should not be overwritten / a new walltime parameter introduced.