Component

https://github.com/camunda/camunda-bpm-platform/tree/master/engine

Steps to reproduce

1. Deploy a process model as in the attachment.
2. After starting the process, one token will be in the wait state and one token will reach the merging inclusive gateway.

Observed Behavior

• Merging gateway does not trigger, but waits for an additional incoming token

Expected Behavior:

• Merging gateway triggers immediately

Implementation notes

Reasoning:

• BPMN Spec (https://www.omg.org/spec/BPMN/2.0/PDF) table 13.3 says:

  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.

The second and third point are crucial here. While the token at the user task might still arrive at the gateway, it must not be waited for, because it may also arrive on a sequence flow that was already signalled.

To determine this, the process engine must store on which sequence flow a token arrives at the gateway. This can be done by extending the ACT_RU_EXECUTION table and expanding the https://github.com/camunda/camunda-bpm-platform/blob/master/engine/src/main/resources/org/camunda/bpm/engine/impl/mapping/entity/Execution.xml mapping.

Forum post: https://forum.camunda.org/t/process-stuck-at-inclusive-gateway/8939

See CAM-12074 for a detailed explanation of more failure cases and some discussion. Failing tests have been added on branch https://github.com/camunda/camunda-bpm-platform/tree/CAM-12074.