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

Write migration tests for legacy behavior due to CAM-3455



    • Task
    • Resolution: Fixed
    • L3 - Default
    • None
    • None
    • engine
    • None


      In the course of CAM-3455, we have made some changes in the execution tree for the following constructs in 7.3:

      Changed behavior:

      • event subprocesses are now scopes and are represented by an additonal execution
      • sequential multi-instance creates an additional multi-instance scope that is represented by an additional execution
      • multi instance: receive task and call activity are now scope but were not scope before
      • concurrent && scope executions in 7.2 (e.g. created with non-interrupting boundary events and event subprocesses) are in 7.3 always represented by two executions, one concurrent with a scope child
      • multi-instance: async job definitions reference the mi-activity, not the mi-body; should work for the mi-body though
      • start instances with 7.2, check activity instance tree with 7.3. (reason: Refactorings in PvmExecutionImpl#getParentActivityInstanceId and PvmExecutionImpl#replace)
      • Error propagation for instances that were started in 7.2 and that is triggered with 7.3 (reason : the error propagation flow scope walker might make wrong assumptions about scope activities and executions due to event subprocess being scopes now)
      • a compacted tree: one execution that is asyncBefore before a non-scope task; now a non-interrupting event subprocess triggers; check whether in 7.2. the concurrent root now has an activity instance id; if not, the getActivityInstance-Command might not work correctly (background: in 7.3 it now definitely has an activity instance id and it seems it wan't that case before)
      • delete a process instance with 7.3 that was started with 7.2; make sure the end listeners are invoked correctly

      Known problems:

      • parallel gateway uses ActivityExecution#leaveActivityViaTransitions which in turn uses PvmExecutionImpl#createConcurrentExecution to create executions for more than one outgoing sequence flow. PvmExecutionImpl#createConcurrentExecution implements legacy behavior for expanding a compacted tree. In 7.2, this legacy behavior was only seen when executing non-interrupting events, but it was not seen with parallel gateway because PvmExecutionImpl#takeAll created concurrent executions correctly


      • write integration tests that start processes with one engine version (7.2.) and complete them with the current (7.3) with legacy behavior turned on and off


        This is the controller panel for Smart Panels app


          Issue Links



                thorben.lindhauer Thorben Lindhauer
                thorben.lindhauer Thorben Lindhauer
                0 Vote for this issue
                1 Start watching this issue