Child executions not removed when activity is interrupted

[jloureiro]

[attachment=0]problem_report.png[/attachment]
The image above represents how a part of my process is modelled:

• There is a "normal" process flow which consists of completing a user task and proceeding.


• Escalation emails are sent based on timers.


• The normal process flow is not interrupted by escalation: the timer boundary events are non-interrupting.


• Additionally, the normal process flow can be interrupted by a user. I modelled this by attaching an interrupting signal boundary event to the task and having a signal delivered upon some user action.

The process works as intended when the normal flow is followed: when the user task is completed, the process proceeds regardless of whether or not escalation emails have been sent and the executions associated with the escalation emails (if any) are destroyed upon leaving the inclusive gateway.

However, if the flow is interrupted by catching the signal, the executions associated with escalation emails, which are suspended on the inclusive gateway, are never destroyed (I know this by inspecting the Activity database, table 'act_ru_execution'). The original user task is interrupted as expected, though.

This causes problems later, as Activiti will fail to terminate the process instance due to the referential integrity constraints.

Is this the expected behaviour? Since the user task is interrupted by the signal, I expect the inclusive gateway not to wait anymore, since no other sequence flow will arrive.
Or is this a bad approach to my use case?

[frederikherema1]

Since the escalation-timers are not untrusting the activity, try letting them go to a separate end-event instead of the inclusive gateway, as they do now.

Nevertheless, all other boundary-events should be destroyed when the signal-boundary-event "cancels" the activiti. Maybe this is related to the use of the inclusive gateway. I'll check if this is the case or not, will come back. In the mean time, try the workaround I suggested.

[jloureiro]

I applied the suggested workaround with success, thanks.

As a side note, I can mention that I took inspiration from this article for that style of merge (i.e., using an inclusive gateway).