Hello Community,
I’m experiencing an issue where an automation is triggering script calls twice for every run. This behavior started around midday yesterday. Is anyone else encountering similar “double-run” issues right now?
This typically happens when there are multiple edits made to a row in a series and all edits meet the Bot trigger criteria. For example, a user adds/edits a row and then actions on the Form Save ALSO edit the row. Each of these counts as a separate edits and are INDIVIDUALLY tested against the Bot criteria to determine if it should run.
The best way to prevent duplicate triggers is to use a column that is expected to be edited only once with the series of edits and then explicitly test before and after conditions.
As an example, let’s say you want a notice sent ONLY when some work row is marked with the COMPLETED status. If you were to use the expression [Status] = “COMPLETED”, then any row edit made after that status is set will trigger the bot and send the notice.
However, you can implement an expression that will trigger the Bot only when the status CHANGES to COMPLETED. You would use an expression like this:
AND(
[_THISROW_BEFORE].[Status] <> “COMPLETED”,
[_THISROW_AFTER].[Status] = “COMPLETED”
)
Note: If the status can ever go back to not completed and then set to COMPLETED again, the BOT would trigger again. There can be other variations of this expression that work just as well.
I hope this helps!
2 Likes
Hello Willow,
Thank you for the response. This is a scheduled bot that is only triggering on a slice of specific rows. The rows must have a status of “Pending” and the first step when triggered by the bot is to change the status to “Proccessing”. The bot only grabs the top record from the slice to proccess at once. The bots are spaced 4 minutes from eachother to prevent crossover and the total run time is typically 1-2 minutes. The duplicate script runs are fired within seconds of eachother and can only be called via the automation. The logs all show the same data and as well row timestamps for the same record. The automation monitor also shows only one run per proccess as well as the one row relation. Hope this helps!
If this is the case, then the bot itself is not running twice. I guess I don’t understand what exactly makes it seem like there was a “double-run”??
Please note, since it sounds like you have multiple Bots running close together, while Bots may TRIGGER at the time you specify, they will not always RUN immediately. Depending on system resources they may get queued and take several minutes before they actually run.
2 Likes
The double run is being preformed from one automation. The automation is firing once and then is causing the script to be triggered twice. This has just started midday yesterday. The automation profile was even more extreme as to be once every minute. The once every 4 minutes was to see on that queueing issue with bots. Then after digging deeper in the logs there wasnt a queueing issue for the bots. They are just simply triggering the script twice per automation run.
I assume you have the Scheduled Bot set as “For each row in table”. Could it be picking up multiple rows? If it does, each one would be listed separately in the Monitor.
Without seeing your Bot and data, I can only guess at causes OR its a service problem.
Looking at prior posts (at the bottom of this one) there have been periodic complaints of duplicate runs/triggers. They don’t indicate a resolution so either they found the problem or it was resolve by Support.
2 Likes
The filter condition for the automation run is as follows - IN([Row ID], TOP(Slice[Row ID], 1)) . It only ever grabs one row. This isnt a coding issue as it is a bug. Hope is to get more traction if there are other users in the community who are experiencing this kind of issue. This way the case id for the support team has more grounds.
Then your only recourse is to open a ticket to AppSheet Support.
If I get a chance, I’ll try to see if I can replicate it in a simple app.
3 Likes
Case has been elevated to the specialist team. Will keep this updated as it goes along.
1 Like
Initial Findings
AppSheet support initially found that the TOP() function was behaving unexpectedly. When configured to select a single record, it was instead grabbing two records simultaneously. This caused multiple automation runs to trigger for separate rows at the same time. This issue was further compounded by bots triggering duplicate child script calls, resulting in several similar scripts firing within seconds of each other. The root cause of why the automation profile is not performing as expected is still under investigation.
Resolution Steps
To restore the expected behavior of the TOP() function, we performed the following steps:
-
Removed the security filter for the target table.
-
Allowed the automation to trigger several times without any filters applied.
-
Re-applied the security filter and saved the changes.
This process corrected the function, which now properly selects only one record. While this addressed the immediate symptom, the underlying cause remains unclear. It is worth noting that this application previously experienced unrelated automation failures that have since been resolved.
4 Likes
Yikes! Not entirely surprising, though. My understanding is the client-side and server-side implementations of the expression engine are distinct (not the same codebase). There are several inconsistencies.
5 Likes