When creating records through an internal AppSheet API call, it seems that the records created in one step ARE NOT immediately available in subsequent steps.
What ends up happening is:
And FYI: my API call is not asynchronous
____________________________________________________________________________________________
My thought was to try and use return value:
Too bad these features aren't plug-and-play. ๐
Hey,
keep it a No Code Platform ffs dude ๐
@MultiTech wrote:
What ends up happening is:
- The records are created
- The next task runs WITHOUT these new records.
I recently encountered a specific need and now I'm stuck. Are there any other solutions? @MultiTech
I found that using brute force works; try using a select statement to pull the records from the database.
I don't think I tried this for my issue. I'll give it a go and report back.
I have ALWAYS found issues with adding/editing rows with an API Task and those changes being available to subsequent steps. I spent considerable time trying to find a way to get it work AND I opened a couple posts and a ticket to AppSheet - only to be told basically that's the way it works. Baloney! I know better! Well - at least is doesn't HAVE to work that way!
I finally split up the workflow into several segregated Bots and that worked - it seemed the newly added rows were now "properly" available to the subsequent Bots. This ran fine for over a year ALTHOUGH, it would occasionally hit a Time Out error.
However, sometime between 11/22/23 and 12/20/23 even the segregated Bots stopped working. There was a release that was rolled-back during that time that I think had changes to automation. I believe the roll-back didn't put the state of the automation back to the "usual" state. But how do you prove that?
I could get a part of my issue to work by adding a Wait step. Which told me that there was just a DELAY in the rows being made available. But it didn't work in all areas, I think because each Wait is a minimum of 5 minutes and adding more than 1 creates a process(es) that run too long - maybe? Adding a wait on condition did NOT work, again because I think there is a delay in the rows being added AND/OR they are NEVER made available to THAT instance of the API at all (which based on past expereince I believe to be the case).
I am still having these issues and spent the time creating Actions in the app to CORRECT situations when an incomplete set of rows are inserted. I have to monitor things more closely but it works for now.
My plan is to convert the set of API calls I have into a Google script. While the API calls are faster than using an Action-based solution, they are still wicked slow and can encounter Time Outs.
@MultiTech wrote:The next task runs WITHOUT these new records.
Hey man,
it's just out of scope is all there is. Nothing really to do with async but rather with task parallelisms
User | Count |
---|---|
43 | |
26 | |
23 | |
14 | |
11 |