Race conditions in bubble

I have had a number of issues in my application where the data types are not consistently being updated by workflows. Every single time I contact support, after a week or longer their answer is ‘Oh, its a race condition’.

That is a completely unacceptable answer. Something that I can do in literally any other database is somehow impossible in bubble.

I have a workflow that creates 5 items and then update the user with the relevant information. This workflow runs twice. It turns out, bubble is so poorly designed that it’s incapable of updating the user datatype quick enough.

Supports suggestion is to slow down the workflow so that they don’t interrupt each other. Seriously? Slow things down? Doing ANY kind of database updates in bubble is already glacially slow, laughably so.

To anyone looking to use Bubble for your application, think again.

This doesn’t even make sense, why would workflows be interrupting each other. If you create a thing, then just update the user’s field referencing the result of the creation step.

Sounds like you’re creating things and doing a search afterwards assuming everything happens in sequence


This doesn’t even make sense, why would workflows be interrupting each other. If you create a thing, then just update the user’s field referencing the result of the creation step.

Yeah, that sounds like what you should do right? That’s exactly what I’m doing.

Create a thing, update the user to include the thing. There is no search, the second step is literally update the user with the result of the first step. The workflow is run twice, once for each course, but due to a race condition, the user is not being updated in the second step on every run.

Ive come across this issue several times in Bubble and their response is always, yeah thats a known race condition. If the system can’t update the same data type within a few seconds of each other, something is very wrong with the system.

If this were true, Bubble wouldn’t be in business.

You’ve categorized this post as “Need Help” but haven’t provided the material necessary for anyone to help.

I’m not a fan of some of Bubble’s more recent decisions but if they spent all of their waking hours trying to solve requests like this, we’d still be on the old responsive engine.

If there’s one thing this forum is good at, it’s solving problems. I suggest you provide context around your issue so some of the big-brains in here feel motivated to help out.


Sounds like you’re doing an “add” to the same list field very quickly in different steps? I have heard of some weird behavior with this if that’s what you’re doing

I’m not saying Bubble shouldn’t be able to handle this, but there might be workarounds or workflow re-structuring to it reliably…

Can you create the 5 things, and set the list to all 5 combined at once?

1 Like

Will update the post with how its currently designed. I hope that it just means redesigning the workflow steps but right now, this is my 5th try on this and every single time it results in a race condition.

I tried recursive workflows and it still hit a race condition.

For more information on how I keep hitting racing conditions, something that doesn’t happen when I’m doing this in literally any other database when building software.

Application is a learning platform with managers that can enrol one or more team members to one or more courses at the same time. Courses can have revision courses.

For the case I sent to support it is adding a single user to a single course with a revision course.

From the dashboard, they select the user to enrol, click “add course” .


  1. This will schedule the users-enrol backend workflow which is recursive.
  2. If the course has a revision course, schedule the same workflow again with the revision course.

  1. triggers a log (for testing and debugging)
  2. Triggers CP Create (problem in this custom event)
  3. Triggers PS Decrease (not important but always works)

Step 1 always fires, step 2 does not, step 3 does.

Step 2 details:


Step 3 also has a make changes to user that doesn’t fire consistently. This workflow is also recursive.

The create things in both of these are being created, they are just not being added to the user in the make changes to user step.

I could run this add course action 5 times and 3 of the 5 times the make changes to user works. Then i could run it again and it would work 100% of the time, but the issue here, its not consistent.

@NigelG I’ve followed several suggestions for recursive workflows on here, but for these workflows, they results are completely inconsistent. I probably have built it wrong but when the only “support” i get is ‘add more delays’ isn’t really an answer when things are already so slow.

Is this enough information to pinpoint exactly where I’m going wrong?

Thanks for your insights @NigelG

So what you could do is move that Step into the create-module-progress by passing in the Course Progress thing. Then update the user in the each iteration of that in one go.

What do you mean here? Move the create-module-progress to where? Its a recursive workflow because there is more than one module progress that needs to be created for each course progress. It also needs the course progress created in step one when scheduling it.

Could I replace the make changes to a user with database triggers? So when the course progress is created, trigger add to user then? Or would I hit the same race condition again?

Thanks @NigelG It looks like that has worked ! I’ll do some more testing shortly, but it appears that its doing what its supposed now.

In the future, I’ll stop treating bubble like its a code based system with a standard RDBMS because it very much isn’t. It would have been great if support had told me that 2 months ago when I came across this issue in another part of the app.

Hopefully this helps someone else.

Edit: I’ve updated the title for it to make the topic usable during search. Apologies to all, I’ve been very frustrated with the slow responses from support and the not so helpful suggestions.