cancel
Showing results for 
Search instead for 
Did you mean: 

Error Boundary Event - execution not closed properly

mdaviot
Champ in-the-making
Champ in-the-making
When a BpmnError is raised in a service task, the execution associated with the Boundary Error Event is not closed properly and the process instance stays open even after the End Event.

I have just created this issue with a unit test.


Would some Activiti developper please confirm that it is actually a bug ?

Thanks and regards
Michel
6 REPLIES 6

jbarrez
Star Contributor
Star Contributor
Thanks for posting the issue with unit test. We'll check it.
Watch the issue for any updates.

mdaviot
Champ in-the-making
Champ in-the-making
Some feedback on this … if you set the propery "cancel activity" to true on the error boundary event, the execution is closed properly.

Maybe this is just a lack in the documentation …

I still wonder, what sense does it make to have "cancel activity" set to false on this event ? Why is it false by default ?

Regards
Michel

frederikherema1
Star Contributor
Star Contributor
It's false by default for ALL boundary-events, if omitted.

I'm not sure what the behavior of a non-interrupting catching error-boundary-event is on the execution-path that threw the error. So you're point whether it makes sense or not to allow "cancelActivity=false" is a valid question.

smirzai
Champ on-the-rise
Champ on-the-rise
Lets return to basics about this topic: in section 13.4.3 of BPMN reference document it is clearly mentioned:

"if the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer, and Conditional
Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event"

So for Error Boundary event, engine should neglect the value of "Cancel Activiti" property and I can consider current behavior as a bug.

Joram, frederikheremans: do you confirm this ? if yes, I can try to fix it.

jbarrez
Star Contributor
Star Contributor
So for Error Boundary event, engine should neglect the value of "Cancel Activiti" property and I can consider current behavior as a bug.

I'm not sure actually, if I read the spec.

But from a logical point of view … why would you want to stay in that step when an error occurred … so I'm leaning towards your interpretation, actually. Did you find anything else in the spec (i just had a quick search)?

smirzai
Champ on-the-rise
Champ on-the-rise
I fixed the problem in, "act-1421" pull request.

The designer should not also allow to set cancelActivity for Error Boundary event. So I created  an  issue to track it in http://jira.codehaus.org/browse/ACT-1447