Open dougnukem opened 10 months ago
Task index and id are not the same, the index is the the order within the process where as the id is the order within the entire pipeline
Also, the task hash will be null because it hasn't been computed yet
Task index and id are not the same, the index is the the order within the process where as the id is the order within the entire pipeline
Also, the task hash will be null because it hasn't been computed yet
@bentsherman hi, what do you mean by "within the process"? There should be only one index for each process, right?
In other words, every task belongs to the pipeline run but also to a particular process. If you have two processes FOO and BAR and they each generate one task, and let's say the FOO task is generated first, both tasks will have task.index
of 1 because they were the first tasks generated within their process. But the FOO task will have an id of 1 and the BAR task an id of 2, because the FOO task was generated first across the entire pipeline run.
Bug report
I'm trying to add
resourceLabels
to each process to track a Task ID so I can associate to a particular workflow task/process from my trace log / execution.nextflow.config
When trying to use this in a
process.resourceLabels
closure function (e.g. to tag cloud resources with the workflow task index/id). It appears thetask.index
is set to the index of the process being run NOT thetask_id
In the documentation it states that the: Process implicit variables
But it appears the
task.index
corresponds to the index of the task that's being run (it happens to be the same ID if the workflow contains only sequential steps).It also appears that
task.id
is null in this context?e.g.
trace.txt
The labels set on the task / process are as follows:
Expected behavior and actual behavior
Expectation is that either:
task.index
corresponds to task_id in the execution tracetask.id
is NOT null and corresponds to task_id in the execution trace and is available in the task configuration closures likeprocess.resourceLabels
task.hash
could be used but it also appears that the hash output by the trace table is a truncated hash (is there a way to get the trace to output the full hash)Steps to reproduce the problem
(Provide a test case that reproduce the problem either with a self-contained script or GitHub repository)
Program output
(Copy and paste here output produced by the failing execution. Please highlight it as a code block. Whenever possible upload the
.nextflow.log
file.)Environment
Additional context
(Add any other context about the problem here)