BUG: Wait for Condition - Improper processing order causing updates to be overwritten.

[WillowMobileSys]

There seems to be a discrepancy in the way a Wait for Condition is processed between the Test account and a deployed app in production.

I am creating a feature that displays a "processing" indicator in my app - a GIF image as a busy indicator - when there is some long running automation involved with a user request.

I have two flags I am setting

1. Processing flag - a y/n column - to show the Processing image.
2. Bot trigger - a text field with the name of Bot to trigger

The Bot trigger and Processing flag are set together. Then immediately the Bot trigger is reset to blank to prevent duplicate triggering of the Bot.  So there are 2 edits sent to the server.

When the 1st edit is applied, the Bot triggers  and performs its activity.  It contains a Wait for when the Bot trigger is blank.  When the Wait is fired it resets the Processing flag to stop showing the image.

Everything works as expected in my test app under my personal account.

The Issue

In the prod environment for the deployed app, it appears that the Wait is fired, resets the Processing flag AND THEN THE SECOND EDIT IS APPLIED TO THE DATA which flips the Processing flag back to the previous state.

I believe this is incorrect processing order and is not how it behaves in the test environment for me currently.  There, the second edit is applied to the data first and then the Wait fires.

[Steve]

Escalated.

[Zhifeng_Lin]

Hi, 
There should not be any difference for the wait step between prototype app and deployed app.

Please contact our support (with access permission to your apps), and our team will look into it.

Thanks!

[Zhifeng_Lin]

@WillowMobileSys also a quick check is to "deploy" your test app (or "undeploy" your prod app) to see if you see the same discrepancy within the same app when it's deployed vs undeployed.

thanks!