Flow concurrency in Appgyver


I wanted to ask a question in which orders are the flow branches executed, so I decided to test it first to get some material first.

I have created a simple app - pressing the button triggers the flow and sets variable below:

Here is what I observed:

  • I created Top branch first and then Bottom branch. As expected after pressing the button the text was “Bottom branch”
  • After visually switching places of both modules. The result was the same. “Bottom branch” even though visually it was on the top. So the flow execution order does not take visual placement - which make sense - it could get trickingy in some cases.
  • Next step I have disconnected “Top branch” (techically at the bottom now) and connected it again. After saving and test result was “Top branch” - great we changed the order.
    -However after any modification to the flow e.g. attachingToast module to “Bottom module” (technically on top on my screenshot) - the flow has reversed to original order.

What I can figure out is that the execution order follows the order of creation? It might be possible to change it , but there are more factors at hand.

Any thoughts from Appgyver team? @Harri_Sarsa

AFAIK each branch is executed in the order as it’s connected to the node depth-first.

What does it mean? Depth -first?

That it goes one branch to the end before starting the next.

Oh yes, now I understand.

How about parallel branches? which one goes first?

My test were giving inconsistent results.

Im not 100% sure but I think it goes like this.

Component tap determines which edge was added to itself first, and starts executing. This branch is executed to the end before going to the second node of the Component tap node.

From my testing it goes this way:

  • We create “First branch” and connect it a component.
  • We create “Second branch” and connect it to a component.

Save, execute. “Second branch” gets executed second.

Now we disconnect “First branch”, save, connect the “First branch” again.
Save, execute. “First branch” gets executed second.

This would make a lot of sense, but from testing, any change to component logic (even attached to a different button) and Save, reverts to original order of execution, “Second branch” becomes executed as second.

This is an isolated simple scenario, but with more logic components connected it would be good to know the order rules.

Hmm didn’t know about this recalculation when doing any changes to the canvas. Maybe we should summon @Kimmo to this conversation if he has any deeper knowledge of what’s happening.

@Greg_F, yeah, as you see in your tests, the order of the execution in this case cannot be trusted, unfortunately. This is because of the asynchronous nature of the logic flow functions.

In this case, when you have two very simple “set variable” functions, this might feel confusing, and I agree with you with that. However, let’s assume that you are using some other flow functions, e.g. “Get record”, that load data from Internet. When in parallel like this, these two requests will indeed be executed concurrently, in parallel, which is a good thing for performance! However, you can never be sure which one completes first! This depends on many factors such as network, server loads, etc.

I’d summarize it like this: when you have two flow functions in parallel, you should never make assumptions about their completion order! Even in this case with two “set variable” flow functions!

Instead, as a rule of thumb, I personally recommend you to always put the flow functions in sequence when their completion order matters!

Hopefully this clarified things a little bit! So, the answer to your question “which one is executed first” is “it is uncertain” and the reason for that is because flow functions are asynchronous!

1 Like

Hey @Kimmo !

This is a perfectly clear answer! Very good to know.

This way if parallel is really necessary, it could be solved by building a delay and if check for a result of other branch, but this starts getting tricky. As you say following sequential order might be best choice.

Really appreciate the answer!

Good to hear I could help!

As a side node: we are aware that managing parallel flows is quite difficult right now. For example: execute two server requests in parallel and wait for them both to complete, and only after that continue the flow. Currently you could use e.g. page variables to store some state of the execution flows, but we have visions for features that could make creating such flows much easier in the future.

1 Like