What processing happens in automation after a Data Change step?

[WillowMobileSys]

I have an automation that experienced a timeout on a simple Data Change step that was simply updating 2 flag columns in a single table row.  I do understand there is an automation processing limit of 2 minutes on each step and 5 minutes for the overall automation.

According to the Monitor logs, this simple Data Change step ran for 124 seconds - just over the 2 minute threshold so it seems this single step caused the timeout.

I am trying to figure out why the 124 sec run time.  The spec states "execution time" so I assume this is based on CPU time not just duration since the process started.  Which means, if my process was paused for some other long running process, it would not count towards its time limit.

So my question is this...

What other processing time is being included along with a simple Data Change step? 

App Formula triggers and Virtual Column re-calcs?  A full Sync?  Something else?

[SkrOYC]

Well, App Formulas (real or virtual columns) are evaluated when you edit the row, so even if you are touching one column with a simple expression (like the two flags you mentioned) AppSheet is evaluating the whole row.
This behaviour is expected for some of us and is the reason we can update App Formulas on real columns using automation and a simple number column doing +1.

Now, I assume you are already thinking on ways to prevent this, and the quick solution would be to move all of the app formulas that don't need to be calculated while editing the row and could wait the row save to be calculated to a form save action.
I use Group actions all over the place called "TableName | Form Save" and then I through each App Formula as part of a "Set the value of some columns in this row" action that's added inside the Grouped one.
Now, be careful with long expressions, your "Save" click/touch could start to feel sluggish if those expressions are expensive.
Well, those are my 2 cents anyway, hope it helps

[WillowMobileSys]

---

@SkrOYC wrote:

AppSheet is evaluating the whole row.

---

Yep, this I understand. But a single row of updates/re-calc's wouldn't amount to over 2 minutes of execution time.

With respect to Virtual Columns, maybe the thinking is that all rows across the app must be re-calculated because ANY of those Virtual Columns MAY depend on the change that was just made?  So maybe a full Sync is performed after each step in the automation?

As I try to analyze this I get more questions than answers.   Currently, I am running with the assumption that I need to clean-up/improve the Virtual Columns within that particular table.

[SkrOYC]

---

@WillowMobileSys wrote:

2 flag columns in a single table row

---

I overlooked this, so you are literally saying that the bot is just there to update one row and it fails because of a timeout.

I'd take a look at child tables for that table and their corresponding data, as with sync time I saw that the [Related whatever] columns can reduce sync time because of those related rows being evaluted.

---

@WillowMobileSys wrote:

As I try to analyze this I get more questions than answers

---

Sadly we are on a situation where we have no clue on what's really going on in the backend, which shouldn't be the case if you ask me

[WillowMobileSys]

---

@SkrOYC wrote:

I overlooked this, so you are literally saying that the bot is just there to update one row and it fails because of a timeout.

---

No, not the bot, just this step in the bot.  There are two steps prior to the problem one that I am ignoring.  

Monitor Error message

***************

[SkrOYC]

Are you using App Script? Maybe it's related to that?

[WillowMobileSys]

No.

[dbaum]

FWIW, over the last few weeks I've started receiving this error a lot for certain automations. It has coincided with a bunch of factors (e.g., changes to app design, changes in app usage pattern, potential AppSheet bugs/changes) that I'm trying to tease apart.