Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-4527

Synchronous interruption of active event-throwing activities does not cancel their execution

    Details

    • Type: Bug Report
    • Status: Open
    • Priority: L3 - Default
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: engine
    • Labels:
      None

      Description

      Various events (e.g. signal, escalation) that synchronously cancel the triggering activity do not actually stop execution at that activity.

      For example, see the attached process model.

      Desired behavior:

      • when "In Subprocess Task" is completed, then only task "Event Subprocess Task" should be active

      Current behavior:

      • when "In Subprocess Task" is completed, both "Event Subprocess Task" and "After Subprocess Task" are active
      • the execution tree is in an invalid state: there is the process instance (A) and a scope execution (B) for the event subprocess. B executes "Event Subprocess Task", A executes "After Subprocess Task"

      Similar cases can be constructed with escalation events (though a little less obvious) and message events (though sending messages within one process instances is not foreseen by BPMN).

      Root cause:

      • the decision criterion whether to continue execution after throwing an event is either not existent (signal events) or too weak (escalation events)

      Implementation notes:

      • the Execution#isEnded flag should be checked before continuing execution; perhaps there is a good way to do this in a cross-cutting manner

      Test case: https://github.com/camunda/camunda-bpm-platform/commit/9a8b6326a4abca1e22ea3dd7052f297b3446e677

        Issue Links

          Activity

          Hide
          meyer Daniel Meyer added a comment -

          the Execution#isEnded flag should be checked before continuing execution; perhaps there is a good way to do this in a cross-cutting manner

          https://github.com/camunda/camunda-bpm-platform/pull/171/files#diff-28c3391a010dd3cf10d60a1a4e7434a3R66

          Is this strong enough?

          Show
          meyer Daniel Meyer added a comment - the Execution#isEnded flag should be checked before continuing execution; perhaps there is a good way to do this in a cross-cutting manner https://github.com/camunda/camunda-bpm-platform/pull/171/files#diff-28c3391a010dd3cf10d60a1a4e7434a3R66 Is this strong enough?
          Hide
          thorben.lindhauer Thorben Lindhauer added a comment -

          Could be, I am not 100% sure without looking deeper into the pull request.

          While looking into the behavior, I noticed that #isEnded is not always an indicator that nothing should happen with an execution anymore. Think of a subprocess with a single task followed by a none-end event inside. When the subprocess scope execution executes the none-end event, Execution#end is called although there are still some AtomicOperations to perform with that ended execution (like CompositeActivityBehavior#complete until PvmAtomicOperation.TransitionDestroyScope). My initial idea for a fix was having an #isEnded guard in the FlowNodeActivityBehavior#leave method. However that does not work for the above reasons.

          Show
          thorben.lindhauer Thorben Lindhauer added a comment - Could be, I am not 100% sure without looking deeper into the pull request. While looking into the behavior, I noticed that #isEnded is not always an indicator that nothing should happen with an execution anymore. Think of a subprocess with a single task followed by a none-end event inside. When the subprocess scope execution executes the none-end event, Execution#end is called although there are still some AtomicOperations to perform with that ended execution (like CompositeActivityBehavior#complete until PvmAtomicOperation.TransitionDestroyScope). My initial idea for a fix was having an #isEnded guard in the FlowNodeActivityBehavior#leave method. However that does not work for the above reasons.
          Hide
          thorben.lindhauer Thorben Lindhauer added a comment -

          On a second thought: No, I don't think the condition you linked is strong enough, since it would execute end listeners a second time in the example process model of the bug description. It would ensure though that no follow-up task is executed.

          Show
          thorben.lindhauer Thorben Lindhauer added a comment - On a second thought: No, I don't think the condition you linked is strong enough, since it would execute end listeners a second time in the example process model of the bug description. It would ensure though that no follow-up task is executed.
          Hide
          meyer Daniel Meyer added a comment -

          Yes, that was my feeling too

          Show
          meyer Daniel Meyer added a comment - Yes, that was my feeling too

            People

            • Assignee:
              Unassigned
              Reporter:
              thorben.lindhauer Thorben Lindhauer
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development