L3 - Default Scenario:
- a process instance X that has called another process instance Y
- Y is active and in a user task A
- Task listener on START and END event of A that accesses stable execution properties, such as activity instance id (stable with respect to tree compaction/expansion)
- X is deleted, cascading to Y
Current behavior:
- END task listener on A sees an invalid activity instance id
Expected behavior:
- END task listener on A sees the correct activity instance id (which should be the same instance id that was seen during the START listener invocation)
- phrased differently: the END listener should be invoked before the activity instance is destroyed; this makes sense, because the task is bound to the lifetime of the activity instance, so the task should be deleted before the activity instance
Reason:
- Tasks that are removed during delete cascade are deleted after their owning execution is cleared and leaves the current activity instance
Another variant of this:
- Variables of the owning execution are not accessible anymore when the END listener is executed; similar reason: variables should only be cleared after the task has been removed
Test case:
Side notes:
- Why does this problem not occur for tasks of the super process instance? They are deleted beforehand, see https://github.com/camunda/camunda-bpm-platform/blob/7.6.0/engine/src/main/java/org/camunda/bpm/engine/impl/persistence/entity/ExecutionManager.java#L82
- This problem should exist with any feature that relies on ExecutionEntity#deleteCascade logic, for example terminate end events