Bad behavior using Parallel Gateway with 2 end events

[wberges]

Describe the bug I create a simple workflow with 2 parallel NON EXCLUSIVE AND ASYNC branches (I want to be able to execute both branches really in parallel), each one finishing by its own end event.

When I start the workflow, everything seems fine according to the log (no exception, all branch messages displayed)

and the workflow diagram shows it is finished

But according to the UI and the DB, it isn't the case: UI - still running DB - EXECUTION: DB - RU_ACTINST: ALL activities with an END_TIME

Expected behavior I would like to:

1. see that there's a problem (Optimistic Exception) in the log
2. see a retry on the branch(es) that failed (if any)
3. no more see the workflow as running (no more EXECUTION, no more history in ACTINST)

BTW we can't configure an end event like we do for a gateway (which may be exclusive and async), so no way to handle a possible optimistic exception locally at this end event. The only possibility to be able to retry only this end event is to add a dummy task which may be exclusive and async and so fail then retry without impact on the previous steps in the branch. Adding exclusive and async attributes to an (end) event would be useful.

Code The corresponding APP ZIP file TEST_PARALLEL_END.zip

Additional context Flowable 6.7.2 in Tomcat 8

[tijsrademakers]

Hi, can you check if you have a dead letter job for this process instance?

[wberges]

Hello Tijs,

No, nothing in DL (logic considering no exception in logs). :(

[wberges]

Hello, No news on this bug? BTW we have the same problem using an inclusive gateway. Thanks

[tijsrademakers]

Hi,

We are not sure this is a bug at this moment, because having a parallel gateway split without a join is not considered a good way of modeling this in BPMN in general, but definitely when the tasks are async and not exclusive I would say not using a parallel gateway join is even worse. Did you try this with a parallel gateway join as well (setting that gateway to async and exclusive).

[wberges]

Hi Tijs,

Sure, the standard way using JOIN in exclusive + async works. (hopefully :))

I don't know if this way to design a BPMN is part or not of the standard (not able to find something about this use-case).

• In a design point of view, if we have to start one or several small parallel branches (e.g. do a 1-step action with a long duration) when the main branch is huge, it's graphically clearer to add an end event to keep a small branch (and it's compliant with the token theory approach).
• But in the implementation point of view, I can understand the behavior: each token finished successfully in each branch, but there's no token synchro in any element, so the workflow is not aware that it is supposed to be finished... :)

So bug or not will depend on what the BPMN standard says?

Thanks in all cases :)

[wberges]

BTW here's an extract of Flowable documentation: https://www.flowable.com/open-source/docs/bpmn/ch07b-BPMN-Constructs#multi-instance-for-each

[wberges]

FYI if I set the tasks BRANCH_1 & BRANCH_2 as EXCLUSIVE, the workflow ends.

[PinoEire]

Hi there. I’m looking at Flowable reliability and support to evaluate its implementation in a critical system.

I’m worried about finding bugs like this one that have no answers and is still open after a long time. Is there a rationale behind this

[wberges]

Hello, No news about this issue? Thanks

[wberges]

Hello, No news about this issue? Thanks

BTW if available, we could have used links to avoid drawing a very long branch to the same final end event (in all cases, still a workaround).

[tijsrademakers]

We didn't have time to look into this yet, but it's still something we would like to make sure that the process instance is in a correct state for this specific case.

[wberges]

Hello, No news about this issue? Thanks