I had a behavior that seemed strange to me when using process instance modification through http calls through postman…
The scenario is as follows:
We had a problem that caused an incident in task 1 (Buscar cadastro Asaas), so I deployed a new processDefinition so that the new instances created by our application started correctly, and in this flow that had a problem in this task, I tried to do the modification of the instance, migrating it to service task 2 (Cadastrar cliente Asaas) see IMAGE 1.
I made the POST call to the Modification API passing the attributes as in IMAGE 2, (I wanted to migrate from task 1 to task 2)… however when executing this call, the instance simply disappeared from all the processes it was in. Below image of the HTTP POST call to the API.
When I looked at the instance in question in the History API to check what happened, I noticed that the “state” is marked as “EXTERNALLY_TERMINATED”, as in the image below:
Could it be that there is no wait state anymore between task II and the end event? That would explain the behavior as follows: the modification instructions are executed in the order you submit them. So if you start the new token first, it will run until the end event and be consumed. Then you cancel task I. So the overall process instance gets cancelled, which is what EXTERNALLY_TERMINATED expresses.
Hello @thorben!
Thank you very much for your reply!
Our process is entirely automated, so I don’t have waiting states on Camunda until the end of the process, but I have some Async Befeore points to persist the data in Camunda’s DB… however from this stage onwards i used instance modification, we still have several other services tasks to be executed and they have not been called, including calls to external services.
In conversation with my brother @Jean_Robert_Alves he said that he has already experienced the same problem, and what he is doing to avoid it is making the request in 2 steps, one that just creates the new instance token as desired, and then makes a request separately to cancel the unwanted “token”.
After some testing for this specific scenario, i found that the following request can be made using transitionInstanceId.
Below is what i did to solve it, so that future users who have the same question can find the answer they’re looking for:
In this case, the activityInstanceId field must be replaced by transitionInstanceId passing the executionId of this transition instance that you want to delete.
As you can see, i started 2 instances using a specific id, as these are 2 activities after a parallel gateway, and finally in the same request i performed the “cancel” using the executionId of the instance that was used to create the other 2 new ones instances.
Programmatically this can be done with the following steps:
We execute instance modification to create the new instance in the desired task.
We look for the executionId of the transition instance (instance you want to delete) through the GET process-instance/{processInstanceId}/activity-instances API.
Finally, we execute “cancel” by passing the value obtained as executionId from the step above, in the transitionInstanceId field.
This process can be carried out even if the modified instance is experiencing an incident.
