Boundary Error Event on SubProcess not cancelling signal

[mhanrahan]

Hi,

As part of our process, we have an inclusive gateway that branches to a Signal Catch Event as well as to a Call Activity.  In normal execution, the child process will signal the parent process and continue on to another inclusive gateway that will continue when both branches are complete.

However, with an exception scenario, that signal is never sent, and an error gets thrown and caught at the edge of the containing sub-process and continues to a human task for fallout handling.  The problem is that the Signal Catch Event is still active, even though the sub process that it is part of has been interrupted by a boundary event.

I have attached an image (just save and remove the .txt at the end) that shows what state the process is in after this has occurred.

So I guess my question is that is this intended behaviour for the process engine or not? If it is, is there a way to get around it so that the signal event is no longer active?

Regards,
Michael Hanrahan

[jbarrez]

No, the signal should be removed in that case.

Can you make a simplified unit test that still shows the problem? That would help us tremendously in fixing it!

[mhanrahan]

This example should reproduce the problem.

[jbarrez]

Hmm this looks like a real bug. I thought that, if i switched the seq flow so that the signal wait would be done first, tht it would work (due to the way activiti leaves a gateway), but it doesn't. It seems deeper than that.

Does it also happens when there is a wait state first in the call activity (eg a usertask BEFORE the throw error), which is then completed first?

[mhanrahan]

Attached I have added another test case for this scenario.

[mhanrahan]

Has there been any progress on your side of things for this issue?

If not, has there been an issue raised? ( I can create one, I just need to know there isn't one already there so there aren't duplicates)

[jbarrez]

No, no progress. Did you respond to my question

> Does it also happens when there is a wait state first in the call activity (eg a usertask BEFORE the throw error), which is then completed first?

I'm guessing it has to do with the fact that the signal is immediately after reaching the subprocess is fired. Hence why adding wait states would shed light on the issue.

[mhanrahan]

Yes, it still happens after a wait state (And I posted an updated Test Case to allow you to reproduce that scenario)