Canvas App Threading

[Dlabar]

Does anyone know how threading works in Canvas Apps functions when it comes to behavior functions?  I have a confirm button with an OnSelect that Selects Button "A" and Button "B".  Button A's OnSelect Performs a call to an Azure DB, and then sets a context variable with a result.  Button "B" checks for this variable and determines what screen to navigate to next.  With this setup, Button "B"'s function is executing before Button "A" sets the context variable.  My work around is to select Button "B" from "A".

Given that Select() calls get put on a queue according to the documentation and that the functions are ran in JS by the end of the day, my hypothesis is that anytime a function performs a call to get external data, it's done async via a promise, then allowing other functions to run, resulting in Button "B" getting executed before Button "A" actually sets the context variable.  Can anyone confirm or deny this hypothesis?

This would mean as long as you don't do any external data calls from an OnSelect, the buttons will execute completely in the order in which you've Select-ed them, but if you do any sort of external data calls, other queued Selects will be called, and if two Select calls on the queue have external data calls, then you've introduced a potential race condition.

[Pstork1]

I don't have any insider knowledge, but it is also my understanding that calls in PowerApps are done in an async fashion.  However, I would suggest that is not limited to external calls. One of the issues I hear regularly from people is that App.OnStart won't always create collections or variables before the controls on a screen try to use them. I would suggest this is the same kind of Async behavior where onstart and initial screen load run in parallel and one is not waiting for the load of another. I find it safest to consider everything happening in PowerApps to be Async and program in such a way that things update as data changes.

[Dlabar]

I reached out to MS and was told the following was true:

1. Whenever multiple control is selected, they are placed in a queue and processed FIFO per documentation.
2. Formulas are a blocking process until ran to completion or until a call is made to a connector (DB, Flow, CDS, etc).  Whenever this happens, formula execution is yielded to the App, where 0 or many items will process (either from the queue in item 1, or another internal app process) before the formula continues processing
3. Given statements 1 & 2, calling Select on multiple controls will result in each control's OnSelect being processed to completion in the same consistent FIFO order, unless one of the OnSelect formulas calls a connector, in which case processing of the formula will yield to the app, and there is no longer a guarantee that the OnSelect formulas will finish in the same LIFO manner in which they were triggered.
4. Therefore, if any formula selected (A) has any (direct or indirect) dependency on another selected formula completing that has a call to a connector (B), formula (A) must be called directly from formula (B), after the call to the connector in (B) to guarantee execution order integrity (i.e. no observable race conditions)

[mwardm]

I'm not sure conclusions 3 and 4 are correct, Dlabar - or at least they're not the full picture.

(Can't state categorically, I'm only just learning here.   And I'm running in an embedded canvas app on a Dynamics 365 CA form. However...)

I've combined two statements in a single button's OnSelect using a semi-colon.

The first statement is a Refresh(someDataSourceOrOther) ; the second is an if statement based on the data in the refreshed datasource.

I've concluded that the If statement is being run before the Refresh has completed, because it evaluates as if it's using values from the previous retrieval.   It would appear the Refresh is being set running asynchronously, therefore.

Mike

[Dlabar]

I have a separate issue logged in the docs for defining what refresh actually does. It could be that there is a bug with whatever datasource implementation that you're using that processes the refresh asynchronously, but the function is called synchronously. I have no idea.

I am a little worried that it truly doesn't run synchronously, because then there is no way to actually ensure that you're retrieving the latest version of the data.

[HelpfulBit]

Thanks for the insight, @mwardm ,

I am working through this with the ModelDrivenFormIntegration.  Values from the form are not present when referenced in the App Onstart, Screen OnDisplay, or the first call of the ModelDrivenFormIntegration.OnDataLoad, which runs when the app loads, immediately calling a Refresh, but the refreshed values are not available to subsequent chained statements.  Only after saving the form to get to a second call, are the values available.  

Are you aware of a way to implement a callback for these, such that the app can reference the values once retrieved in an action formula?  For my purposes, a non-action formula will not work.