I don’t use lists as often as others, I think. I’ll only really use lists for static, non-changing data e.g user permissions, settings, maybe preferences. Or, if I need to store something in order for whatever reason. Sure, searches might consume a bit of WU and be a tad slower than lists when the lists are very short, but it sure saves headaches with storing lists… Generally if > 10 items I’ll just go with search rather than list structure. Objectively slower + more expensive than list up until maybe 50, but more reliable.
2 Likes
Same generally. There are many good use cases for lists though, just depends on the context, how often they are edited, risk of breaking, etc.
This is such a great news. Thanks team! 
Let me include couple of questions that are crucial to be answered:
-
Are we gonna have any type of insights on individual workflows inside scheduled workflows on a list. If some of the workflows inside fail can we know what happened?!
-
Does this upgrade cover only
Schedule API Workflow on a Listor it coversMake Changes to a List of Thingsas well?! -
Is 100k limit really 100k?! Or would you recommend to using lower number in real life just to be sure and safe?!
3 Likes
This is good to know. So “Leaving this empty (recommended” for the interval (seconds) parameter, is only recommended when the scheduled API is working on distinct records, otherwise a mess will ensue (unless an interval is added).
Sooooo… pretty much this 
PS: Hopefully this is true and we can work with this operation instead to get performance boost! 
Note that in many instances, you cannot achieve the same granularity as you can with BWFs and hence this (big) improvement will not always apply.
Understood, but lists don’t really impact race conditions too much as the list host thing is only modified to link to the items in the list (which can be done as a batch for all list things at a later time).
However, race conditions aren't only an issue with lists. Any time there's incoming API WFs that can impact a thing (e.g., Stripe telling us the payment is cancelled), a race condition can occur. And it's not going to be common but if data integrity needs to be 100% then it still has to be handled.
Including legacy dedicated plans?
1 Like
People have been reporting issues with their backend workflows, and upon investigation it seems that this update has been making race conditions appear in their apps. To be fair, the race conditions were already present due to design of the apps, but they were only triggered by this update.
This is a great improvement and i’m really grateful for the performance/stability upgrades however you should have kept existing values for interval(seconds) in order to keep workflows spaced out and avoid breaking people’s apps.
Despite this hiccup, congratulations on the update and thank you for the work. Performance and stability upgrades are awesome.
2 Likes
Yeah that’s a safe assumption. If you don’t specify, they will now likely run so fast that they will almost certainly conflict. But yes, not an issue if making changes to distinct records.
I agree. They should have left the existing default numbers for sure.
Hi everyone! It’s great to see the overall excitement. I wanted to jump in and help address a few topics that have come up:
- It’s true! The limit is really 100,000 and will work in any scenario you are likely to attempt.
- As others have helpfully pointed out, the issue highlighted by @Onerbarisoner looks to be the result of a race condition introduced by the increased concurrency of the workflows. The immediate fix is to set the interval to something relatively long, like 2+ seconds. We’ll look to provide more guidance around this in our documentation.
- This update is only applicable for the Schedule API Workflow on a List action. There is no change to the behavior for other actions on a list as part of this release.
- This update is available for all apps on plans with dedicated servers.
- Observability is an area we are actively looking to improve and will provide further updates in the coming months. As a starting point, the ‘Finished running action’ log for the Schedule API Workflow on a list action now includes the number of successfully scheduled workflows (see example in screenshot).
7 Likes
That’s a significant step into the right direction. Next logical step would be to make frontend loops less awkward 
6 Likes
This issue has been around for a while. Bubble does not handle well at all multiple workflows occuring at the same time operating on the same data entry. I had a client app that incurred the same issue, and one of my own apps as well. The way I solved for it was to run workflows as a chain because Bubble support took the approach that it is not a bug but is an issue of too many workflows running simultaneously (which is a bug that Bubble can not handle it but…)
1 Like
@steven.harrington this would be a great time to add the feature for backend workflows to have a workflow error trigger available…been after that for years now.
That is successfully scheduled, not successfully ran, correct? So the idea is that we are seeing the number of things in the list we scheduled for, but not how many from that list successfully ran and were operated on?
3 Likes
Exactly. The downside of running it as a chain is that it can’t take advantage of the performance improvements brought by this update. For now, I’ve solved it by checking if this is the last element in the list in each workflow, along with some waiting. (Though there’s no guarantee that the last element in the list will run last…)
Can you remove the fact we have to upgrade from the legacy use this?
1 Like
Pretty nice improvement. Everything have been said. Just wondering if the Wf has 10 or twenty actions how it will handle it. This is not the same to have an action than 20…
Was aware of the race issue, and of another too, confirmed by support : interval less than 5sec are not respected. I went crazy one day with this… all wf were running at the same time where I had setup 2sec…
@steven.harrington are you sure about an interval less than 5sec?
This is exactly the reason why I can’t switch over, way more so than capacity which I’ve never actually had huge problems with. I need result definitions and a last run trigger.
I’m running into the exact same scenario as @onerbarisoner where I have a Create a Thing A in step 1 and a Add Thing A to list of Things A in Thing B in step 2.
I understand that workflows are now running simultaneously, and that’s a great step towards better performance. However I’m still having trouble understanding how such a basic workflow can fail from a logical standpoint. When looking at the logs, step 2 seems to be running correctly and should add the record created in step 1 based on its unique ID:
I’m ok with adding more time between occurrences, or using a recursive workflow instead, but I’m a bit confused as to why this improvement is causing this. Imo Step 2 should always run after Step 1 of the same occurrence (even if several occurrences are running simultaneously) and therefore the action should still run correctly. Makes me wonder if going back to recursive workflows isn’t more reliable for this specific use-case. Shame given the nature of this improvement imo.