chore(child workflows): updated all sdk docs to clarify how to ensure a child started before a parent completes#4538
chore(child workflows): updated all sdk docs to clarify how to ensure a child started before a parent completes#4538flippedcoder wants to merge 2 commits intomainfrom
Conversation
… a child started before a parent completes
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📖 Docs PR preview links
|
| A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is scheduled from within another Workflow using a Child Workflow API. | ||
|
|
||
| When using a Child Workflow API, Child Workflow related Events ([StartChildWorkflowExecutionInitiated](/references/events#startchildworkflowexecutioninitiated), [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted), [ChildWorkflowExecutionCompleted](/references/events#childworkflowexecutioncompleted), etc...) are logged in the Workflow Execution Event History. | ||
| When using a Child Workflow API, Child Workflow related Events ([StartChildWorkflowExecutionInitiated](/references/events#startchildworkflowexecutioninitiated), [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted), [ChildWorkflowExecutionCompleted](/references/events#childworkflowexecutioncompleted), etc...) are logged in the Workflow Execution Event History. The Child Workflow needs to have an _Abandon_ [Parent Close Policy](/parent-close-policy) set in the Child Workflow Options. |
There was a problem hiding this comment.
Why was this line about parent close policy added?
There was a problem hiding this comment.
I shuffled this line up from below and updated it a bit. Is the Parent Close Policy optional? I think I remember something about it defaulting to Abandon.
There was a problem hiding this comment.
Yes it is optional, I don't think this sentence makes sense here.
| To be sure that the Child Workflow Execution has started, first call the Child Workflow Execution method on the instance of Child Workflow future, which returns a different future. | ||
|
|
||
| Then get the value of an object that acts as a proxy for a result that is initially unknown, which is what waits until the Child Workflow Execution has spawned. | ||
| You should block progress on the Parent Workflow until the [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event is logged to the Event History to ensure the Child Workflow Execution has started. If the Parent makes the `ExecuteChildWorkflow` call and then immediately completes, the Child Workflow Execution doesn't start. In Python, you can make sure your Child Workflow started by awaiting `execute_child_workflow`. |
There was a problem hiding this comment.
In Python, you can make sure your Child Workflow started by awaiting
execute_child_workflow.
I realized my statement in slack was misleading, execute_child_workflow also waits for completion, not just starting. But start_child_workflow is what ensures the workflow has started. I believe this applies to all Core SDKs. Java should follow Go
There was a problem hiding this comment.
Ah, ok. Thanks for helping me clear that up!
What does this PR do?
Some of the explanations in Go for how to ensure a Child Workflow started before a Parent completes were copy-pasted across all the SDKs. Except for Java, which is similar to Go, simply awaiting a Child Workflow method means it's started. This updates all the SDKs to clarify the differences.
Notes to reviewers
┆Attachments: EDU-6321 chore(child workflows): updated all sdk docs to clarify how to ensure a child started before a parent completes