Add jobLogger output for subworkflow running (with parent and subworkflow ID) #7387
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
The current cromwell docker log has UUIDs for sub-workflows only appear when they produce relevant output. This means you can go from looking at one root workflow to suddenly needing to know a UUID that is a sub-workflow of a sub-workflow. It is hard to follow the logs without a peek at something telling you the structure of the workflow (i.e., the cromwell-executions filesystem or the metadata).
This change adds output so a sub-workflow logs: ParentWorkflowID, SubWorkflowID, and RootWorkflowID. When the sub-workflow gets run. basically looking like:
INFO -
<ParentWorkflowID>
-SubWorkflowExecutionActor-SubWorkflow-name:shard:attempt [UUID...] - Running subworkflow:
<SubworkflowID>
, root:
<RootWorkflowID>
INFO - ecb081a4-0166-4f9f-a2a8-20a50f8e9b19-SubWorkflowExecutionActor-SubWorkflow-outer_subworkflow:-1:1 [UUID(ecb081a4)SubWorkflow-outer_subworkflow:-1:1]: Running subworkflow: 53f62151-1c36-4e2f-8bff-0a2a90d7d8c5, root: ecb081a4-0166-4f9f-a2a8-20a50f8e9b19
This output goes to the cromwell docker log and the root-workflow's cromwell-workflow-log. Still complicated, but at least now you have a chance to follow along.
Note, every time
pushWorkflowRunningMetadata
is called it is for a new UUID for a new sub-workflow. And thesubWorkflowId
is known so that's why the log output line was added here.Example from a simplified real world WDL
In the example below (which has been edited to make it easier to read). We have several examples of sub-workflows calling other sub-workflows.
Without the
Running subworkflow
output suddenly you're seeing output referencing 9 new UUIDs without any idea of what they are. This kind of output pops up a lot when you have reference/library style tasks in a WDL where a lot of the work happens inside several levels of sub-workflows.Details about the example WDL
main_workflow.wdl
) creates a subworkflow (LEVEL_1),call outer.outer_workflow
outer_subworkflow.wdl
then creates a scatter of 2 across another subworkflow (call inner.inner_subworkflow
/LEVEL_2A and LEVEL_2B)inner_subworkflow.wdl
/LEVEL_2A and LEVEL_2B then runs a task with a scatter and a scatter of 3 across a final subworkflow (call sub_workflow.sub_subworkflow
/ LEVEL_2_X__3_Y)sub_subworkflow.wdl
then runs a scatter across a task:In tree form you have something like this:
main_workflow.wdl
outer_subworkflow.wdl
inner_subworkflow.wdl
sub_subworkflow.wdl
sub_subworkflow.wdl
sub_subworkflow.wdl
inner_subworkflow.wdl
sub_subworkflow.wdl
sub_subworkflow.wdl
sub_subworkflow.wdl
LEVEL_2
inner_subworkflow.wdl
task outputs end up here:And LEVEL_2_X__3_X
sub_subworkflow.wdl
task outputs end up here: