Clarify the structure and usage of run.workflow for sub-workflows #1123
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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In the schema, there is a
run.workflowelement that defines a sub-workflow.However, it’s not entirely clear how this definition is supposed to be used.
The
workflowdefinition currently specifies the following properties:namespacenameversioninputAs I understand it, a sub-workflow should behave similarly to a regular workflow — meaning it should at least contain a
dodefinition or some equivalent execution logic.It would be helpful to clarify:
dosection,specification/schema/workflow.yaml
Line 783 in 833d25d
Beta Was this translation helpful? Give feedback.
All reactions