After running a task on a custom state that holds 40 database entries and setting their status to “Queued,” I immediately trigger a Scheduled Workflow on a List. The first step of the backend workflow updates each entry to “In-Progress,” but only 30 change right away. The rest remain in “Queued” until a slot becomes available, which can sometimes take 2 to 3 minutes.
Also, even more crucial to my app, this limit doesn’t apply per user, it’s shared across the entire app. So if multiple users are each running tasks (even small ones with 5–10 items), they all compete for the same 30-slot queue and slow each other down.
Can someone tell me if I’m doing something wrong or is this expected behavior in Bubble?
Yes, I tested with 1 and 2 second intervals. The limit still applies. In this case, items get scheduled one by one, but once the 30th item is reached, the rest stay in the queue. I also tested using a recursive “Schedule a Workflow,” and that hits the same 30 limit as well.
Others can still schedule workflows while it’s working through the list one by one, as long as it hasn’t hit the 30th item yet, but once that limit is reached, everything else goes into the queue.
I also confirmed that, all users and all “Schedule a Workflow” actions across the app share the same queue. So even if someone else schedules a completely different workflow, it still counts toward that shared 30-slot limit. This is so weird.
Might be the limit for run away workflows. I forget what it’s called but in settings we can set how many runs a recursive flow can go until bubble will stop it. If that is set to 30, it might explain it and lead to it being a bug affecting schedule on list because it is not supposed to.
That’s the issue, originally, the Queued state was cosmetic and just meant to flash by and immediately switch to In-Progress, but I was surprised to see some of them actually stop there.
I’m not sure what it might be then or how to resolve without being in the editor and taking a deep dive. Definitely seems odd, but because it seems to be always the same number of 30, it could be a bug. I’d recommend reaching out to support and reporting a bug unless somebody else on the forum knows what it is.
Alright, I’ve submitted a bug report. I’ll be back here tomorrow if there’s no resolution by then and I’ll reach out to coordinate a time that works for you to take a look. If nothing works out, I’ll probably move the logic to n8n, have it send an immediate response, and let it continue processing in the background before reconnecting with the final result.
