Running into an issue where some “items” are not added to a user’s list of “items” as part of a backend workflow.
Scenario.
A user retrieves a list of items from an API, and schedules a Backend Workflow on a list.
The backend workflow saves each item from the retrieved list, with a 15sec delay between each item. (the list will in general contain between 10 and 30 items.
As part of the same workflow, each items is added to Current User’s list of Items, using the result of step 1.
My understanding of how workflows are executed is that if a subsequent workflow step is using the result of a previous step, it should always wait for the step it depends on to complete before executing itself.
On average it takes less than a second for bubble to save the Item from the list to the database, so 15 sec between saving a new item should presumably be plenty of time to avoid two things ever being written to the same list at the same time, in case bubble would find that problematic.
Not exactly (I think)…as per my understanding it simply is supposed to smartly know how to properly map the data upon execution or thereafter if the data was not available.
It is a custom trigger that really forces the subsequent steps to not initiate until the actions in the custom trigger have completed.
The use of result of previous step and custom trigger are similar in that they are supposed to ensure the data of previous actions is available for the subsequent actions that require them, but I think are slightly different in how that happens.
You may try to set up with a custom trigger involved rather than rely on the result of previous step, especially if that previous step is the API call.
I stopped using these about 3 years ago when a Bubble engineer told me to. I reported a Bug related to a feature that used schedule on a list, and the engineer told me to use a recursive backend workflow instead. I’ve never since used it, and always use recursive backend workflows and never have any problems with their functionality. I can run recursive backend workflows on a list of API results with multiple field arrays and string together a series of recursive backend workflows and let it run for days without issue.
You may want to consider setting it up as a recursive backend workflow rather than schedule on a list (sometimes it may take a bit longer to complete, but they should always complete properly)
Have you checked the logs to see what actually is happening? Or the capacity to see if app timed out?
My belief was that both a custom workflow and a “result of step…” should behave the same way here, and triggering a custom workflow let’s you do the same thing when your have no result from a previous step to rely on. I can’t remember if I was told that by support or heard from someone who was told by them. I’ll reach out to support to clarify that.
Wowza, that’s a bit troubling to hear since it’s a pretty core feature of their API connector. I couldn’t find anything about it in the documentation either, for a known issue. If I can’t solve the issue I will definitely file a report about that. Sounds like something that should be part of the documentation or rectified.
So that was the interesting part, according to the logs, the “Item” was added to the user’s list of “Items”. Which is was confused me so much about the whole thing. But now that you mentioned it, I went back over the logs again and found that, yes, it was added, but it was the first item on the list and it was added at the exact same time as the second Item on the list. Which could have caused it to bug out.
Which shouldn’t have happened, with a 15sec delay. And then I noticed that subsequent Items were added 2 seconds apart. Which very much sounded like the default behaviour of the scheduled workflow on a list. (where bubble does a guesstimate and decides on a length of time itself)
So then I wen’t over the workflows again, and found that there is one place in the application that triggers the workflow (it can be trigged in more than one place), and in this one place, I had missed setting up a 15sec delay. Lo and behold… that was the workflow that had ran. So in the end… there was no 15 sec delay at all.
I’ve now fixed that and will run this a number of times over and see if it is reproduced. Hopefully it is not, which would also explain why the workflows in other parts that has the 15sec delay never misbehaved.
Anyway, thank you man, your reply helped me second guess myself enough to go back over the logs.
What is being expressed here is that recursive workflows are the (vanilla Bubble) solution.
However, the vast majority of iteration cases could be solved by Bubble simply adding a map function in Expressions. (And as I’ve said before, the :filter operator already has everything we need, UI-wise, to make this possible.)
There’s scant little that Bubblers desire to do (iteratively) that couldn’t be solved by that. But Bubble is Bubble. Ever shall it remain.
