New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Workflow] Cascading terminate and purge #6393
Comments
Question to anyone monitoring this issue: should the cascade behavior be enabled by default or should it be opt-in? I'm leaning towards making it the default behavior since I think it will be the most common case. |
Cascading would be the default behaviour for me, and generally echos what people have said over the years on the DF product too. I assume the cascade would be eventual given the unbounded nature of things to terminate? |
Thanks for the feedback.
Correct. Terminate is already asynchronous and the cascading terminate would also be asynchronous. Also, the expectation will be that parent workflows will typically be terminated earlier than the child workflows. |
Will there be a way to monitor the termination so that one can know when they all complete? |
This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions. |
bump |
/assign |
FYI, an implementation has been added to the I haven't done any work for cascade purge, however. That may require a very different implementation since purge is not a history item like terminate is. |
This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions. |
/keep-alive |
This change fixes issues in current implementation of Cascade Terminate and adds support for cascade Purge. It is required to support dapr/dapr#6393. As per current implementation, Each language SDK must implement the cascade terminate feature A failed sub-orchestration in the chain might block termination of its own downstream sub-orchestrations This PR moves the recursive termination logic to backend side and so no SDK would need to have any implementation. Also it fixes the issue of failed orchestration blocking termination of its downstream sub-orchestrations. It also adds a new test to validate both scenarios. (The second test added failed for the original implementation.) This PR also implements Cascade Purge, similar to Cascade terminate and adds tests for the same. The Proto updates are corresponding to the protobuf updates: microsoft/durabletask-protobuf#20 Signed-off-by: Shivam Kumar <shivamkm07@gmail.com>
closed via #7340 |
In what area(s)?
/area runtime
Describe the feature
There should be an option when terminating or purging a Dapr workflow to also terminate/purge any child workflows it has created. Currently, each child-workflow must be terminated/purged independently.
Release Note
RELEASE NOTE: ADD Cascading terminate and purge of child workflows
The text was updated successfully, but these errors were encountered: