AnsweredAssumed Answered

Strange timer boundary behaviour

Question asked by lmollea on Oct 16, 2014
Latest reply on Mar 2, 2017 by ami
I experienced a "curious" behaviour on a user task with a boundary timer and a output fanout with conditions.

It happened that even if the task was closed, the timer on the task wasn't cancelled and thus fired at the appointed time, causing an unexpected behaviour.

The process which caused the issue is shown in this image.
"Task 3" has 4 output flows 3 of which get activated based on a set of conditions and a 4th one (the bottom one that skips the parallel work) which is activated when all the previous three conditions are not met.
As I mentioned, when completing "Task 3" the process went on to the various legs, but after the boundary timeout on "Task 3" was reached, that boundary timer fired and we had also the task "Timeout Task 3" active.
By launching again the process and looking at the tables, we noticed that the ACT_RU_EVENT_SUBSCR still had a line for the timer on "Task 3" even when only the "Postprocess" tasks were active.
To avoid the problem, the process was changed to this one. The only change is the addition of the inclusive gateway after "Task 3". With this change, no spurious timer is left behind when Task 3 is completed.

To me the two process seems equivalent, but at runtime, they are not. I don't know if this is an expected behaviour or is a bug.
The user guide doesn't seem to imply that this should happen (quoting):
"A sequence flow can have a condition defined on it. When a BPMN 2.0 activity is left, the default behavior is to evaluate the conditions on the outgoing sequence flow. When a condition evaluates to true, that outgoing sequence flow is selected. When multiple sequence flow are selected that way, multiple executions will be generated and the process will be continued in a parallel way."

If this is a bug, let me know, I'll set up a test case and raise an issue.