Using InclusiveGateways in combination with ParallelGateways can lead to deadlock situations in which the process instance waits on the parallel join as well as the inclusive join.

The following situations work just fine

Simple parallel and inclusive (mixed inclusive split with one positive & one negative path)

Parallel and inclusive (all positive split paths) with a backloop

The following however do not work, i.e. the execution will wait on parallel and inclusive join forever

Parallel and inclusive (mixed inclusive split with one positive & one negative path) with a backloop

Parallel and inclusive (mixed inclusive split with one positive & one default path) with a backloop

Spec definition and root cause

The BPMN spec says (table 13.3)

The Inclusive Gateway is activated if

• At least one incoming Sequence Flow has at least one token and
• For every directed path formed by sequence flow that
  • starts with a Sequence Flow f of the diagram that has a token,
  • ends with an incoming Sequence Flow of the inclusive gateway
    that has no token, and does not visit the Inclusive Gateway.
• There is also a directed path formed by Sequence Flow that
  • starts with f,
  • ends with an incoming Sequence Flow of the inclusive gateway
    that has a token, and
  • does not visit the Inclusive Gateway.

In the implementation of the inclusive gateway (https://github.com/camunda/camunda-bpm-platform/blob/7.13.0/engine/src/main/java/org/camunda/bpm/engine/impl/bpmn/behavior/InclusiveGatewayActivityBehavior.java), we check if a token can generally still reach the gateway, but we do not take into account via which sequence flows that is. In particular, we do not consider if a token can also reach the gateway via a sequence flow that was previously already activated. Note that fixing this will therefore require to store the sequence flow via which an execution has reached the gateway (see also CAM-3472).