Scheduled Bot does not update row with Script returned values??

[WillowMobileSys]

I am looking for either confirmation that others are having this issue
…OR that others have successfully implemented a similar process.

Depending on answers I will open a ticket to support.

EDITED: From another conversation thread, I added a Wait step into the Bot between the Script call and the row update. all rows are now properly updating. The theory is that the update step runs before the returned values are ready to be used. This is a workaround that adds to the overall run time. For my use case it is acceptable. Hopefully, AppSheet will resolve this obvious design issue soon.

I have 2 Bots that retrieve miles and hours values from Google Directions service using the exact same function in a Google script. Bot #1 runs via button tapped by the user for a single row. Bot #2 is a Scheduled Bot designed to update a batch of rows that did not get the directions results - i.e it runs on a list of rows.

Images below.

Issue…

When the Scheduled Bot runs, every row reflects in the logs that there ARE indeed returned values from the script. BUT…only a row or 2 (out of batch of 30 plus) actually updates the associated row. The remainder are not updated. There are no errors logged.

If I then manually run each of those rows via the button to execute Bot #1, same process, the rows are updated.

Additionally, if I limit Bot #2 to a single row, the row will properly update. If I limit it to 3 rows, only the first row updates

Attempts to Resolve…

I have tried configuring the Google Script to return an Array of values, as well as an Object. I have also tried turning off all options on Bot #2 - triggering other bots, wait for Sync. The results are always the same.

Conclusion…

I believe that there is an AppSheet bug for Scheduled Bots running with a Script that returns values. Only a few random rows are successfully updating and potentially none at all.

Images

Step to call Google Script

Step that Saves returned values

Log entry reflecting Script return values - good for every row

Expected log result - only occurs for 1 or 2 out of 30 rows

Usual Log result - most rows are not getting updates in the Save Results step

[Steve]

I’m afraid I have nothing to offer here.

[luizluca]

“Me too” here. It looks like the script calls are executed but appsheet forgets about the result in most cases (sometimes for all cases if applied to many rows). It just looks like a racing condition, where the script output is stored in a shared area, overwritten by the subsequent executions.

I contacted the support and they told the that’s “by design” . They suggested to change some data instead of calling a script. That change would trigger an update event, which I could associate with a bot that finally calls the script. However, it looks like changes from a bot process does not trigger events.

I even tried to use appsheet database and the dedicated update event for the database. However, the same non propagation of events occurs there.

[Steve]

It might help to consider the possibility that the bot is acting on each row simultaneously, in parallel. If that were to happen, could it account for the behavior?

[WillowMobileSys]

In my case, I don’t think so. As illustrated every row IS getting back the correct values from the Script. The update to the rows are not being applied.

I cannot think of any reason why parallel row updates would be an issue - UNLESS as @luizluca implies, the returned values are in a shared area and are interfering with each other in some way. I can probably test that.

This would be a big design flaw. I see no difference between a Scheduled Bot running a batch of rows OR several app users performing the same operation simultaneously. If there is an error with the later, it would be a major problem - at least for apps that utilize scripts.

But of course, AppSheet server-side processing is a black box and the handling of the two case above may be completely different.

[Trevwiller]

https://www.googlecloudcommunity.com/gc/AppSheet-Q-A/Returned-Values-from-a-Process-Call-are-being-destroyed/m-p/823324#M255344

I know that this was a thread from this week of @scott192 was experiencing issues with return values from scripts

[MultiTech]

I’ve had stuff like this happen to me before.

• My solution was to change how the script works
  • Instead of returning a value
  • We push an edit to the AppSheet API

Essentially accomplishing the same thing.

Edits through the API trigger automations, so if you need to pick up a “part 2” from the end of the first, you can include an automation trigger in the API edit call to trigger the follow up automation - which can then continue on with down-stream processing.

Definitely something off with the system though, some kind of bug.