You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a workflow using the Flowchart activity has a loop which includes a FlowJoin inside of it, the Flowchart will only start the FlowJoin activity the first time it reaches that activity. On subsequent iterations of the loop the Flowchart will not start the FlowJoin activity once the preceding activity has been completed.
Steps to Reproduce
Create a Workflow with a Flowchart which has a branch which loops around on itself, ensuring that the branch includes a FlowJoin activity within it.
Run the workflow, the first iteration around the loop will execute as expected.
The second iteration the Flowchart will essentially halt when it reaches the FlowJoin.
Expected Behavior
The Flowchart will start the FlowJoin again in the second+ iteration of the loops.
Actual Behavior
The Flowchart does not start the FlowJoin when it runs the second iteration of the loop.
Environment
Elsa Package Version: 3.2.3 (Works in version 3.1)
Additional Context
The check added in #5544 appears to be what has broken this, as FlowJoin activity is added to the FlowScope on the first run, so it's seen as an existing activity when it comes time to start the second run.
From my understanding the check is added to handle the scenario where you have multiple activities feeding into a FlowJoin set to WaitAny, with the intention to avoid the FlowJoin kicking off twice.
Ideally to handle both scenarios the Flowchart would need to be able distinguish whether a parallel activity was joining to a FlowJoin that had already been run, or if it is coming from a chain of activities that have looped back around. I'm not sure if enough context is accessible or even recorded in the Flowchart.
As a workaround in our solution we've inherited the FlowJoin activity and added a behavior where we remove the FlowJoin activity from the FlowScope's activities collection, similar to #5742.
By loop, I'm referring to a series of activities in a flow chart which have connections that will result in them being executed again.
E.g. Activity1 -> Activity2 -> Activity3 -> (back to) Activity1 ...
If one of those activities is a FlowJoin activity, the Flowchart will not execute it a second time, and essentially just halts.
Description
If a workflow using the Flowchart activity has a loop which includes a FlowJoin inside of it, the Flowchart will only start the FlowJoin activity the first time it reaches that activity. On subsequent iterations of the loop the Flowchart will not start the FlowJoin activity once the preceding activity has been completed.
Steps to Reproduce
Expected Behavior
The Flowchart will start the FlowJoin again in the second+ iteration of the loops.
Actual Behavior
The Flowchart does not start the FlowJoin when it runs the second iteration of the loop.
Environment
Additional Context
The check added in #5544 appears to be what has broken this, as FlowJoin activity is added to the FlowScope on the first run, so it's seen as an existing activity when it comes time to start the second run.
From my understanding the check is added to handle the scenario where you have multiple activities feeding into a FlowJoin set to WaitAny, with the intention to avoid the FlowJoin kicking off twice.
Ideally to handle both scenarios the Flowchart would need to be able distinguish whether a parallel activity was joining to a FlowJoin that had already been run, or if it is coming from a chain of activities that have looped back around. I'm not sure if enough context is accessible or even recorded in the Flowchart.
As a workaround in our solution we've inherited the FlowJoin activity and added a behavior where we remove the FlowJoin activity from the FlowScope's activities collection, similar to #5742.
Related Issues
#5544
#5487
#5742
The text was updated successfully, but these errors were encountered: