I am implementing a bpmn process with camunda. My Workflow looks as follows:
As you see tasks A, B and C are user tasks which need to be completed. Sometimes these tasks need to be repeated so i modify the process instance via the rest api.
This modification then starts before the task/activity that has to be repeated.
Now if you complete task A 3 times because you want to repeat it, the parallel gateway no longer waits for all sequence flows to be executed and just triggers the terminate event (needed to kill the trigger notification service task above).
As i understand this seems to be the behaviour of an inclusive gateway, which just waits for a certain amount of sequence flows to be executed. But the parallel gateway should wait for every single one of its joined sequence flows to be executed as far as i unterstand it.
Is this behaviour known?
The BPMN 2.0 specification section 10.5.4 "Parallel Gateways" says:
For incoming flows, the Parallel Gateway will wait for all incoming flows before triggering the flow through its outgoing Sequence Flows.
so technically your expectation is correct. The engine only waits for a number of tokens equal to the number of incoming sequence flows and therefore you get the observed behavior.
How you are work with a repeated execution (and also the trigger) is rather uncommon. Why don't you make the possibility of repeating the task visible in the process? You could for instance attach a message boundary event and loop back into the task (A in your example). Then use the message API instead of the more invasive modification API. This would lead to a process model which better reflects what can happen. Other alternative options to model this better instead of using modification API include BPMNError, Escalation, xor gateway following task, embedded sub process and more.