Hello
I noticed the following behaviour.
If error end event is triggered in embedded sub-process, and this error is not trapped in the outer scope, the token of the main process continues with the next step:
If I call an inner activity, however, and error event is triggered in it, the token in the main process also disappears and does not go to the next step:
Is this the expected behaviour?
Thanks in advance
I found the reason
The token has not disappeared, but is waiting at the converging parallel gateway.
but this is not visible in Cockpit
is it normal that tokens waiting at the gateways are not shown in Cockpit?
Hi @jaxx,
I can’t say if it normal.
When I added a feature to the camunda-bpm-assert library to support assertThat(processInstance).isWaitingAt(parallelJoiningGateway), I found that a different query is required to get the data. The activity statistics didn’t include the information.
Hope this helps, Ingo
Thank you for your reply @Ingo_Richtsmeier
There is another thing related to errors, which puzzles me.
We have the following diagram
At the moment when the error is thrown there are 2 parallel executions - 1 at Receive payment and 1 at the error event. At this moment both execution tokens disappear and a new token appears at the Task handle error - which is the behavior which I expect.
However if the event subprocess does not exist (like this)
when the error is thrown - its own token disappears (as expected), however the other token at Receive payment stays active.
It seems like unhandled BPMN error does not cancel all executions in the scope, while a handled error - cancels them?
Is this right?
Hi @jaxx,
Yes, your finding is correct.
As per the docs,
“The default behaviour in this case is to log information and end the current execution”
" This behaviour can be changed withenableExceptionsAfterUnhandledBpmnErrorproperty set totrue"
https://docs.camunda.org/manual/7.15/reference/bpmn20/events/error-events/#unhandled-bpmn-error
