Hi Thorben,
I have case, where the ID does not remain stable, but it’s actually a transition ID, not an activity instance id. I’m not sure what you expect for those.
So the process consists of start node, service task, and end node. The service task throws an exception and runs out of retries. In this scenario, the exectuion at the service task has no act_inst_id_ in the DB and the activityInstanceTree shows a transitionInstance with the same Id as the processInstance. When I now start a new execution before the service task, both executions have no act_inst_id_ in the DB while the activityInstanceTree shows two transitionInstances, whose IDs are the respecitive executionIds both of which are different from the processInstanceId. So here, the cancel-command would not work.
With this example, can you say if there are more scenarios like this one? How do you judge the scenario?
Best, Peter