Hello,
I found an inconsistend behaviour in the way flowable is handling Event Subprocess handling BPMN Errors.
I have a BPMN like that, designed to handle BPMNErrors occuring at different levels.
ITEM subprocess and subITEM subprocess are multiple instances treating each elements of lists.
Let’s assume the following tasks can throw a BPMNError
- INIT List
- Main Treatment ITEM
- Main Treatment SUBITEM
(in real life i have multiple tasks in each subprocess).
My goal is to handle errors withing the subprocess where it occurs.
The events subprocess are defined without error reference. As i understood, it will make them catch every BpmnError whatever their error code.
`
<subProcess id="subprocess-error-item" name="Handle Errros at ITEM level" triggeredByEvent="true">
<startEvent id="xxx" isInterrupting="true">
<errorEventDefinition flowable:errorVariableName="errorVariable" flowable:errorVariableLocalScope="true" flowable:errorVariableTransient="true"></errorEventDefinition>
</startEvent>
....
`
When I throw a BPMNError From “Main Treatment ITEM” i expect it to be handled by the subprocess “Handle Error at ITEM level”.
However, it is sometimes treated by the “Handle Error at subITEM level” subprocess (i can see it with the logs writtien). And I get a FlowableIllegalArgumentException after the end of this error handling subprocess.
Let’s look at the source code choosing correct the eventSubprocess to handle a BPMNError
Test case : “Main ITEM Treatment” throws a BPMNError
when debugging, i can see that eventMap (l157) countains the 3 subprocesses handling errors.
I guess the order of keys for the loop will depends on the hash order. If I restart my process, the order can vary leading to drasticaly different results
- CASE 1: Order for eventMap.keySet() loop : ITEM ; subITEM ; TOP
First Loop(ITEM) :
currentContainer.getFlowElement(refActivityId) != null [because the ITEM subprocess countains the SubITEM error handling process]
==> matchingEvent is set but it does not have an errorCode so errorCode remains null
==> we dont reach the break;
Second Loop (SubITEM) :
again currentContainer.getFlowElement(refActivityId) != null bec
==>matchingEvent is replaced
==> again we won’t reach the break
Last Loop (TOP) : currentContainer.getFlowElement(refActivityId) == null
==> matchingEvent is not updated ;
It stills refers the “Handle Error in SubITEM” subprocess.
I enter this event subprocess and when it is finished I get
org.flowable.common.engine.api.FlowableIllegalArgumentException: Variable ‘subItemList’ was not found
(which is quite normal as the BPMNError was thrown before the task initializing the list of subitems).
(I relaunch my engine and start again a new process instance with this BPMN).
- CASE 2: Order for eventMap.keySet() loop : subITEM; TOP; ITEM
First loop (subITEM) : matchingEvent is set to the start event of “Handle Errors at subITEM level” subprocess; not reaching the break
2nd loop (TOP) : no change on matching event
3rd loop (ITEM) : matchingEvent is set to the start event of “Handle Errors at ITEM level” subprocess ; still not reaching the break but it is last loop
We enter the “Handle Errors at ITEM level” subprocess and everything is working as expected!!
I guess the problem is that the call to getFlowElement on the ITEM subprocess (org/flowable/bpmn/model/SubProcess.java) contains all the elements of ITEM and subITEM in it’s flowElementMap. So when it is called to check if the ITEM subProcess contains the “Handle Errors at subITEM level” it returns it’s startEvent.
I think the correct behaviour would be to only search for error handling subprocess in the subprocess where the error happens and in it’s parents (starting from the current subProcess to the top process level in this order). Not in it’s children.
Is this a bug or am I missing something?
At least this inconsistence of the selected event handling subprocess seems strange!
ps. I just filled an issue report on github :