martinweiler opened a new pull request, #7257: URL: https://github.com/apache/incubator-kie/pull/7257
Closes https://github.com/apache/incubator-kie/issues/7256 ## Summary When an **interrupting** Event Sub-Process is triggered, the engine doesn't interrupt the enclosing process or sub-process. The parent's other active node instances keep running, and the parent is only aborted when the handler reaches its End Event. If the handler waits on something (a user task, a call activity to a process with a user task, a timer), the main flow stays fully active for as long as the handler runs. ## Spec reference BPMN 2.0.2, §13.4.4 (Event Sub-Process, Operational semantics) and the Activity lifecycle (§13.2.2): - "Once the interrupting Event Handler is started, the parent Activity is interrupted and no new Event Handlers can be initiated or started." - The parent enters the state *Failing* (error trigger) or *Terminating* (any other trigger). It stays there "until the interrupting Event Handler reaches a final state". During that time the handler can still access the parent's data context. - §10.5 (p. 280) says "Whenever the Event occurs ... the associated Activity is interrupted", and that the parent "is canceled after ... the handler completes". So there are two steps. The parent is **interrupted when the handler starts**, and it reaches its **final state when the handler finishes**. ## Current behavior In [`EventSubProcessNodeInstance`](kogito-jbpm/jbpm-flow/src/main/java/org/jbpm/workflow/instance/node/EventSubProcessNodeInstance.java): - `signalEvent()` starts the handler without touching the parent's other node instances. - `nodeInstanceCompleted()` aborts the parent when the handler reaches its End Event. This second step is spec-conformant. Consequences: - The parent's tasks stay active and can still be completed while an interrupting handler runs. - A second trigger can start another interrupting handler while the first one is running. ## Fix In `EventSubProcessNodeInstance.signalEvent()`, before starting an interrupting handler: 1. If another interrupting handler is already running in the same container, ignore the event. 2. Cancel the container's other node instances, except handlers that are already running. 3. Start the handler as before. The abort at the handler's End Event is unchanged. A handler is interrupting when its start node is interrupting and `keepActive` is true, which is the condition the old code already used. Tests: - New process `BPMN2-EventSubprocessSignalInterruptingWaiting.bpmn2` and test `IntermediateEventTest#testEventSubprocessSignalInterruptingWaitingHandler`. The test fails without the fix. - Existing suites show no regressions: `IntermediateEventTest`, `ErrorEventTest`, `EscalationEventTest`, `CompensationTest`, `ActivityTest`, `FlowTest`, `StartEventTest`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
