Timing by which work in the AppSheet queue is proc...

Daisy_Ramirez · 06-15-2022 07:22 PM

Can someone explain the timing by which work requests in the AppSheet queue are processed for bots? We've been monitoring a complex bot and suspect status changes (FILE_SENT_P below) may be getting processed before create file tasks. Is this possible? Here is the current flow of the bot:

On trigger, Wait 10 minutes
Create csv file 1
Create csv file 2
Create csv file 3
Send Email with 3 files attached
Send pdf Email
Create Activity Record 1 (add row from this table)
Set the status field of bot table to FILE_SENT_P
Set the status of child records 1 (execute on a set of rows) - set status field to FILE_SENT_P
Set the status of child records 2 (execute on a set of rows) - set status field to FILE_SENT_P
Set the status of child records 3 (execute on a set of rows) - set status field to FILE_SENT_P
Set the status of child records 4 (execute on a set of rows) - set status field to FILE_SENT_P
Create Activity Record 1 (add row from this table)
Set the status field of bot table to FILE_SENT_P

1minManager

I think I've seen similar issues with bots. From what I recall as soon as your "Send pdf Email" stage is triggered the bot moves onto the next stage. Even though the email may take 5-10secs to create. They way I got around this was to change the order of things in the bot. But you could also consider adding another delay. Or even getting it to do a nonsensical task like adding some data then deleting it to cause a similar delay.

Technically what your seeing is a race condition - https://en.wikipedia.org/wiki/Race_condition

Simon@1minManager.com

Steve

@MultiTech @Marc_Dillon Do either of you have any insight?

MultiTech

First I just want to point out... I notice you've got a bunch of data change actions for child records...

and most likely you're copying over duplicate data.
(The file was sent)

But you recorded that on some higher level already, right?
- Why record it on... EVERY single child record?

There's no reason why, if you need the status of the file from the parent, you can't dereference that when you need it.

[Child_Parent_Ref].[Parent_File_Status]

--------------------------------------------------------------------------------------------------------------

That being said....

This is what I've been told by those building the automation system:
- everything inside a bot runs linearly.

Down the stack
One by one
From top to bottom
AND if one fails, the rest don't fire off

This has been my experience as well. (No matter the complexity)

------------------------------------------------------------------------------------------------------------

I've got all sorts of automation with the following setup:

Create a file and save it in the Google Drive
Put a file link inside a column
Send the file through email to someone

I've never had an email go out where the file wasn't there.

Marc_Dillon

I agree with Matt, Steps within a Process execute serially.

My only guess here would be centered around the "Wait" step. Perhaps it is changing the context of the Bot in some way, or the record is different by the time the ~10 minutes is over, which affects how the execution happens? Why are you using a Wait Step anyways?

What are you seeing that is making you suspect that a later Step is occurring before an earlier Step?

Daisy_Ramirez

Thanks so much for helping to think through this.

The Wait step was inserted to make sure the system had enough time to process the following steps:

Set the status of child records 1 (execute on a set of rows) - set status field to FILE_SENT_P
Set the status of child records 2 (execute on a set of rows) - set status field to FILE_SENT_P
Set the status of child records 3 (execute on a set of rows) - set status field to FILE_SENT_P
Set the status of child records 4 (execute on a set of rows) - set status field to FILE_SENT_P

Since we're executing on a set of rows , we suspected the status' didn't have enough time to run and so the emailed reports would generate but they displayed empty. In this case we're updating the status of the child records at time of transmit because it is possible for users to add data to the record that should not be sent until the records are processed correctly by the users.

Note: The emailed reports should display data for records that are in TRANSMIT status. Once the status turns to FILE_SENT_P the data should no longer be sent.

I believe by the time the emailed report is sent the status has changed to FILE_SENT_P which no longer meets the requirements of the report and sends an empty report.

Marc_Dillon

This all makes very little sense to me.

One of the only things that seems like it would make sense here is that you thought a status changing task was executing before an email and/or file creation tasks, even though it was a later Step in the Process. Is that correct? And so to try and fix that, you inserted a wait step? But why would you put the wait step first, and not in between the tasks?

Am I completely off-base here?

Daisy_Ramirez

Sorry for the delay Marc. Good question: Updating the status to FILE_SENT_P removes the status from the user's view preventing them from accessing the records and adding info to records that are already processed.

I will play with the relocation of the Wait though to see if it works. Thanks

Timing by which work in the AppSheet queue is processed for bots