Environment (Required on creation):

• Any environment with the process engine

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):

When creating a multi-instance process with MI async after (see steps to reproduce), then the activity instance tree cannot be retrieved while the process is in the async after state (e.g. with an incident).

Steps to reproduce (Required on creation):

1. Create a process model as follows:
   • Multi-Instance subprocess
   • Multi-instance async after (so that there is a transaction boundary after every iteration of the MI construct)
   • Sequential or parallel multi-instance (bug occurs in both cases)
2. Create a process instance and let it wait at the async continuation
3. Call RuntimeService#getActivityInstance

Observed Behavior (Required on creation):

• The API method fails with org.camunda.bpm.engine.ProcessEngineException: No parent activity instance with id subprocess#multiInstanceBody:8 generated

Expected behavior (Required on creation):

• An activity instance tree is returned in which the async continuation is represented as a transition nested in the multi-instance body activity instance.

Root Cause (Required on prioritization):

• The command for the activity instance tree creates an activity execution mapping from the leaf execution, i.e. the execution waits at the async after
• This method collects the current flow scope and the flow scope execution (https://github.com/camunda/camunda-bpm-platform/blob/7.17.0-alpha4/engine/src/main/java/org/camunda/bpm/engine/impl/pvm/runtime/PvmExecutionImpl.java#L1530-L1531). It then proceeds to match scopes and scope executions in the hiearchy bottom-up in order to create the mapping
• In our particular case, the flow scope becomes the multi-instance body, not the subprocess, because the subprocess is already completed (end listeners have been invoked, the activity instance id has been removed). However, the flow scope execution becomes the (still existing) scope execution for the subprocess. Then, we have one more execution to match than we have scopes. There is code to deal with this case in the legacy behavior (https://github.com/camunda/camunda-bpm-platform/blob/7.17.0-alpha4/engine/src/main/java/org/camunda/bpm/engine/impl/pvm/runtime/PvmExecutionImpl.java#L1627). It removes the multi-instance body scope from the mapping. As a result, no activity instance is created for the multi-instance body and the tree cannot be generated.
• Also, note that this is not supposed to be handled by legacy behavior (as legacy behavior is for execution trees not created by the current engine). Accordingly, the problem is rather that we call the method for the activity-execution mapping with a list of scopes and scope executions that does not match.
• Side note: Also for non-multi-instance cases, the legacy behavior case was called (e.g.: process contains sub process contains scope activity (async after)). However, in this case the legacy behavior works differently and apparently the problem doesn't bubble up to the API

Solution Ideas (Optional):

• Skip the ending scope execution when constructing the activity execution mapping that the activity instance tree is created for

Hints (optional):