flowable / flowable/flowable-engine
Bad behavior using Parallel Gateway with 2 end events
- Lingua principale
- Java
- Stelle
- 9.5k
- Fork
- 2.9k
- Merge medio
- 7h 8m
- PR unite (30g)
- 2
Descrizione
**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](https://github.com/flowable/flowable-engine/files/10360632/TEST_PARALLEL_END.zip)
**Additional context**
Flowable 6.7.2 in Tomcat 8
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Direzione di ricerca
Inizia con l’applicazione fornita TEST_PARALLEL_END.zip e riproduci il workflow su Flowable 6.7.2 in Tomcat 8, verificando il log, la UI e lo stato nel database di EXECUTION e RU_ACTINST dopo che entrambi i rami paralleli hanno raggiunto i rispettivi eventi di fine. Il lavoro è completato quando l’errore ottimistico segnalato è visibile, i rami non riusciti possono essere ritentati e il workflow completato non contiene più alcuna execution né cronologia delle attività.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- java
- Ambito
- backend
- Tipo di issue
- Bug
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Ferma
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 38/100