Clarify the structure and usage of run.workflow for sub-workflows #1123
-
|
In the schema, there is a The
As I understand it, a sub-workflow should behave similarly to a regular workflow — meaning it should at least contain a It would be helpful to clarify:
specification/schema/workflow.yaml Line 783 in 833d25d |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
@treblereel A subflow is simply a task that runs another workflow. The invoked workflow is indistinguishable from any other—it can also be executed independently. Because of that, it must follow the same rules as other workflows, including defining at least one task in its do section. A subflow doesn’t automatically inherit or override data from its parent. Instead, it receives as input whatever data you choose to pass to it—by default, that’s the current data of the calling workflow. Its output is then returned to the parent upon completion. The subflow runs within the same execution context as its parent. It should therefore be terminated, cancelled, suspended, or resumed along with the parent, unless it’s explicitly not awaited. I hope this clarifies things. See https://github.com/serverlessworkflow/specification/blob/main/dsl-reference.md#workflow-process |
Beta Was this translation helpful? Give feedback.
@treblereel A subflow is simply a task that runs another workflow. The invoked workflow is indistinguishable from any other—it can also be executed independently. Because of that, it must follow the same rules as other workflows, including defining at least one task in its do section.
A subflow doesn’t automatically inherit or override data from its parent. Instead, it receives as input whatever data you choose to pass to it—by default, that’s the current data of the calling workflow. Its output is then returned to the parent upon completion.
The subflow runs within the same execution context as its parent. It should therefore be terminated, cancelled, suspended, or resumed along with the…