Interrupting Notification Event Sub-Process#11048
Interrupting Notification Event Sub-Process#11048DmytroKost wants to merge 3 commits intomendix:developmentfrom
Conversation
| * The sub-process is re-created with the start event of the specified type together with all the event sub-process activities. The new start event can be triggered after the workflow is redeployed and becomes in progress. | ||
| * The workflow will become incompatible if the changed event sub-process is already being executed in one of the ongoing workflow instances. | ||
|
|
||
| The event sub-process is re-created upon type switch because in-place conversion would produce states that contradict BPMN 2.0 concepts. Per BPMN, an interrupting event sub-process cancels the parent process scope and all other active sub-processes the moment it is triggered, while a non-interrupting one runs in parallel without affecting them. These are mutually exclusive execution models: an event sub-process instance belongs to exactly one of them from the moment it starts. Changing the type in place on an already-active instance would leave it in a state that is neither valid interrupting nor valid non-interrupting behavior, violating the fundamental BPMN distinction between the two. |
There was a problem hiding this comment.
What do we mean by type here? I would consider type, timer, message, etc. And this, if I read correctly, is about switching interrupting behaviour.
There was a problem hiding this comment.
@Remcovh "Type" is a pretty general term, but in this context it’s clear we’re talking about switching between interrupting and non-interrupting, so I think it works fine here 🙂
| * The sub-process is re-created with the start event of the specified type together with all the event sub-process activities. The new start event can be triggered after the workflow is redeployed and becomes in progress. | ||
| * The workflow will become incompatible if the changed event sub-process is already being executed in one of the ongoing workflow instances. | ||
|
|
||
| The event sub-process is re-created upon type switch because in-place conversion would produce states that contradict BPMN 2.0 concepts. Per BPMN, an interrupting event sub-process cancels the parent process scope and all other active sub-processes the moment it is triggered, while a non-interrupting one runs in parallel without affecting them. These are mutually exclusive execution models: an event sub-process instance belongs to exactly one of them from the moment it starts. Changing the type in place on an already-active instance would leave it in a state that is neither valid interrupting nor valid non-interrupting behavior, violating the fundamental BPMN distinction between the two. |
There was a problem hiding this comment.
Maybe we can enrich this part with an example
Changing the type in place on an already-active instance would leave it in a state that is neither valid interrupting nor valid non-interrupting behavior, violating the fundamental BPMN distinction between the two.
Changing the type in place on an already-active instance is not possible because switching to interrupting, for example, would require retroactively canceling the parent scope and any parallel sub-processes that may have already completed or progressed.
There was a problem hiding this comment.
I understand the concern about retroactive patching, but the limitation is conceptual, not technical. In BPMN 2.0, interrupting and non-interrupting behaviors are mutually exclusive lifecycles, not toggleable settings. Changing the type mid-flight would create an illegal state that violates the spec, and since we never retroactively patch history or undo completed work, the sub-process must be re-created to ensure a valid execution model moving forward.
4 participants
For 11.10