Stop and resume after error differ depending on service task implementation about bpmn-elements HOT 6 CLOSED

I’ll have a look.

from bpmn-elements.

The joinGateway is an exclusive gateway. Is this intentional? Doesn't affect your discovery, but the execution differs if you actually wait for both the service task and catch error event before continuing.

I've tried to replicate the flow to get the visuals. Is this close:

from bpmn-elements.

Well, as far as I know an exclusive gateway is better since the the two incoming paths cannot occur (the request is succesful or an error happens).

In the test I added a "dumpState" function that dumps the queue status on console. There you can check the different queue status. As far as I understood the difference is that, when an asynchronous (a REST call, or a timeout as in the example) call is made the internal flow reaches down to the process, here the process waits for the two remaining messages to be consumed (the error and the task) and the whole message history is cleaned up (only "leave" messages and the error one is left).

If the call is synchronous (so that a simple call to the callback) the queueing system returns to a higher level and the message history is not cleaned up.

As an end result in the first case when the state is recovered the definition throws an error maybe because in the state message queue there is no evidence of the whole history, while in the second case the process is resumed at the correct point. but this is just guessing, debugging the queueing system is not that easy to me and this is the "finest" (so to speach) level I could get.

from bpmn-elements.

If you use a parallel gateway the gateway will wait for both sequence flows before continuing. One is taken and the other is discarded. When both flows have been touched (taken/discarded) the parallel gateway will complete and take the outbound flow. Once.

The exclusive gateway will behave as any other activity, it will take action on all inbound sequence flows. The discarded sequence flow will touch all downstream flows until it reaches an end or is looped. The taken sequence flow will still do stuff as intended.

So, it's just a matter of offloading the engine of doing unnecessary work.

from bpmn-elements.

Thank you for uncovering this issue. I believe i managed to fix it.

from bpmn-elements.

Thank you for uncovering this issue. I believe i managed to fix it.

apologize for late feedback. I do confirm that bpmn-engine/elements runs as expected and issue does not happen.

thanks.

from bpmn-elements.