I have a simple process (attached) where two external tasks should be executed in parallel. To achieve that I set the first parallel gateway as asyncAfter / nonExclusive (to make tasks’ execution concurrent) and the second parallel gateway as asyncBefore (to create a save point after tasks are executed):
test.bpmn (7.2 KB)
If the tasks finish execution at exactly the same time (that can be simulated in the task’s code), I get an OptimisticLockingException from the engine. As far as I understand this behaviour is expected, but what I don’t understand is why the exception is not automatically resolved by the engine, but is reported as an incident instead!
I have found the following statement in the documentation:
Handling Optimistic Locking exceptions
In case the current Command is triggered by the Job Executor,
OptimisticLockingExceptions are handled automatically using retries. Since this exception is expected to occur, it does not decrement the retry count.
If the current Command is triggered by an external API call, the Camunda Engine rolls back the current transaction to the last save point (wait state). Now the user has to decide how the exception should be handled, if the transaction should be retried or not.
I’m using REST API to trigger the process, so I believe that is the case why an incident is created. Is there a way to resolve the exception automatically (as they are stated to be “expected to occur”) so there is no user interaction required to resolve this exception as it is done when using an embedded Camunda process?