-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[FIX] cannot end a flowchart when a End is Then Activity in If #5899
base: main
Are you sure you want to change the base?
Conversation
Send BreakSignal when executing End Activity
Check isBreaking when a child completed in Flowchart
@dotnet-policy-service agree |
Add test case of Breaking from a While which includes a Flowchart
Add test case of ending a flowchart when the end activity is nested in a If.
Add test case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense. Only thing I'm unsure of is whether we should reuse the BreakSignal
, or if it would be better to create a dedicated EndSignal
. The former is intended to break out of a "scope" such as a for-each activity's Body, while the latter would be intended to complete the closest flowchart activity containing the End activity.
Thoughts?
Good idea! The |
Now the |
Yes, the |
@sfmskywalker Hi. Any thoughts about this pr? |
@@ -27,6 +27,9 @@ public Flowchart([CallerFilePath] string? source = default, [CallerLineNumber] i | |||
OnSignalReceived<ScheduleActivityOutcomes>(OnScheduleOutcomesAsync); | |||
OnSignalReceived<ScheduleChildActivity>(OnScheduleChildActivityAsync); | |||
OnSignalReceived<CancelSignal>(OnActivityCanceledAsync); | |||
|
|||
OnSignalReceived<BreakSignal>(OnBreakSignalReceived); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does the Flowchart activity need to handle the Break signal?
I am concerned about this PR and how it would adversely affect existing workflows. The way that I expect End activities to work is for them to end the current flow. If there is a single flow in the process, then it would effectively end the process. But if there are concurrent flows, only the flow that reached an End should stop - the other concurrent flows should continue until they reach their respective End activities (or complete all activities if no explicit End). This would be a very breaking change for many workflows in our organization. And it would go against how End activities are treated in BPMN. Perhaps there should be a new Terminate activity or something if this new behaviour is required. I think that the current Elsa End activity would be equivalent to then BPMN None End. The proposed new End behaviour would be equivalent to the BPMN Terminate End. |
@bobhauser Thanks for chiming in. You're right, actually. The description of the End activity states as much: it's a milestone event, and an explicit way to mark the end of a sequence. @iio888 what do you think of the suggestion to introduce a new activity called Terminate? Its effect should be equivalent to that of the BPMN's Terminate End, which (I think) is essentially the same behavior as the one you implemented for the End activity in this PR. |
Maybe there is something mistakes in my code. What I want to fix is equivalent to None End actually. As in #5823, I found some potential problems when I am using Thanks for your suggestions. |
fix #5823
Welcome to post suggestions.
This change is