Skip to content
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

Closed
Tracked by #7410 ...
cgillum opened this issue May 23, 2023 · 12 comments
Closed
Tracked by #7410 ...

[Workflow] Cascading terminate and purge #6393

cgillum opened this issue May 23, 2023 · 12 comments
Assignees
Milestone

Comments

@cgillum
Copy link
Contributor

cgillum commented May 23, 2023

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

@cgillum
Copy link
Contributor Author

cgillum commented Jul 10, 2023

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.

@olitomlinson
Copy link

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?

@cgillum
Copy link
Contributor Author

cgillum commented Jul 10, 2023

Thanks for the feedback.

I assume the cascade would be eventual given the unbounded nature of things to terminate?

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.

@clintsinger
Copy link

Will there be a way to monitor the termination so that one can know when they all complete?

@nyemade-uversky
Copy link

nyemade-uversky commented Jul 13, 2023

This looks related to these issues: #6113 and #6457. Making this comment for grouping purposes

@dapr-bot
Copy link
Collaborator

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.

@dapr-bot dapr-bot added the stale Issues and PRs without response label Sep 11, 2023
@olitomlinson
Copy link

bump

@dapr-bot dapr-bot removed the stale Issues and PRs without response label Sep 11, 2023
@shivamkm07
Copy link
Contributor

/assign

@cgillum
Copy link
Contributor Author

cgillum commented Oct 3, 2023

FYI, an implementation has been added to the durabletask-go dependency here: microsoft/durabletask-go#24. I haven't tested it yet with Dapr, and some work may be required to pass in a value to use the new behavior.

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.

@dapr-bot
Copy link
Collaborator

dapr-bot commented Dec 2, 2023

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.

@dapr-bot dapr-bot added the stale Issues and PRs without response label Dec 2, 2023
@rabollin
Copy link
Contributor

rabollin commented Dec 7, 2023

/keep-alive

@dapr-bot dapr-bot removed the stale Issues and PRs without response label Dec 7, 2023
cgillum pushed a commit to microsoft/durabletask-go that referenced this issue Dec 22, 2023
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>
@mukundansundar mukundansundar added this to the v1.13 milestone Jan 2, 2024
@mukundansundar
Copy link
Contributor

closed via #7340

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants