Race condition causes buggy data

[scott192]

I have found a problem where a Bot process and a Grouped Actions process do not seem to have the same data presented to them at their start.  Either that, or using an action to Update a value in a row is actually updating more columns than is suggested.  Let me explain:

I have a Bot that triggers on a Record Add to a table.  This bot calls an Appscript Task that creates, names and returns a FolderID, a FolderName and a FolderURL back to the bot and the bot adds that extra information into 3 columns on the newly added record.  The bot then continues to add a row to another table indicating what has just happened so an administrator can see an audit trail.

Now, while the bot is doing its thing, I have an Action on that newly created record that lets the user add a child record via a Form.  On a FormSave Event, a number of grouped actions run that add grandchild records, update a row in the child record and FINALLY, UPDATE A COLUMN (LastUpdate) in the Parent Record just created.

The problem I am seeing is that if the Appscript Task info (The Folder stuff) has not been written BEFORE the Client Side record stuff was triggered on the Form Save Event, then even if that info was written DURING the granchild adds and record updates the final UPDATE to the Parent record WIPES out the 3 columns filled by the bot despite only one column being asked to update on the client side.

So what is happening here?  I have witnessed the values being written in real time into the sheet and then being wiped again by the client side update a few seconds later.  It's a rare occurrence and all down to user timing.

For now, I have forced a screen refresh at the time the bot runs so that the data is fully synced (a 20 second delay) before allowing any client side actions to run, but my query is to do with how can updating one value in a row force a DELETE on other values in that row?

[1minManager]

---

@scott192 wrote:

how can updating one value in a row force a DELETE on other values in that row

---

If you update anything on a row all the APP Formulas and Reset On Edit formulas are re-evaluated.  Sometimes you have to adapt these formulas to not update under certain conditions.

Simon, 1minManager.com

[scott192]

There are no reset on edits or formulas applied to the 3 fields that are filled from the bot.

I absolutely do rely on "all the APP Formulas and Reset On Edit formulas" being re-evaluated for row updates, but in this case it is not related to the problem.

[AleksiAlkio]

Hi Scott, for me it sounds like the client and its action doesn't have the correct data yet when it's triggered, and when its doing the job, it kind of overwrites the data in your gSheet.

[scott192]

This is what I am saying.  I don't think the server update (made by the bot) is informing the client of data changes to the record that the client is also going to change.

The main problem here though is that it seems that the client is writing more than a record update for 1 column.  It is also DELETING values that have changed with the bot.  Values that were just empty columns when the record was created on the client initially.

[1minManager]

So to be clear you have a GAS running at the same time as the Appsheet Bot?

[scott192]

The GAS is an Appscript Task that returns values to the bot.  The bot places those values into the record that triggered the bot run.  All of that works as it should.  The bot runs server side though and the values placed onto the trigger record are not being communicated to the client side fast enough...consequently I introduce a delay by forcing the app to sync before allowing any other data operations to happen.

[AleksiAlkio]

It kind of delete the value, but as the client has the value as "blank", it writes that value back to your column without knowing there was already a value. The same will happen for example if you first create a record, and then you manually add some values to that row directly in gSheet. If you now modify the row with the app without syncing first, it will change those values with a "blank" value. This is a normal behavior.

[scott192]

Yep, agree totally that it would be normal behaviour for a user amending the sheet directly.  Appsheet only knows what it has in its cached record store that the client side works with.  I cannot think of a way for a server side bot to inform the client that its record cache may have changed.

Only fail safe is to force a client refresh with the bot trigger so that the user cannot operate any buttons on the client or to use the 'Behaviour' section of an Action Button to not show the button until certain columns have data in them.

[AleksiAlkio]

Or hide the whole row until the script has modified the record with those IDs.

[scott192]

Just out of interest...

Why does Appsheet send the whole row to the sheet when it performs a record update?  Why doesn't it instead send just the columns that will have changed...these would be the values set by the user as well as any VC or Formula columns that had been recalculated?  Is it a limitation on the sheets API that it must receive a whole row?

[AleksiAlkio · Accepted solution]

That's what it has been from the beginning as fas as I know. And to be consistent, the API does it in the same way.