The idea is:
Expose the top-level workflow ID and execution ID in custom nodes and the Code node, even within sub-workflows. These values should be available as part of the execution context, regardless of whether the current node is running in the main workflow or within a sub-workflow.
My use case:
We have a number of complex workflows that invoke sub-workflows to handle modular or reusable logic. For observability and audit purposes, we log key actions and outcomes to an external system. However, since each sub-workflow runs in its own execution context, it’s difficult to correlate actions across the parent-child workflow boundary.
Having access to the top-level workflow ID and execution ID from within sub-workflows would allow us to associate all logs and operations back to the original triggering workflow, providing full traceability and simplifying troubleshooting.
I think it would be beneficial to add this because:
- It enables end-to-end traceability across nested workflows.
- It improves observability in logging, error tracking, and auditing.
- It allows developers to implement custom logging and telemetry without having to manually pass metadata between workflows.
- It aligns with common practices in distributed and event-driven systems where trace context is maintained across calls.
Any resources to support this?
- Use cases in observability frameworks like OpenTelemetry, which emphasize trace propagation across services.
Are you willing to work on this?
Yes, other than working out the variable names, this is a very simple change to the Execute Workflow and Execute Workflow Trigger core nodes.