Forum Academy Marketplace Showcase Pricing Features

Is there any solution to "App is too busy" errors?

I have an app with 500+ users that has a major consistency problem.

Due to the nature of the app, I’m often having to create a list of 5-10 things, delete a list of things, or edit a list of things. I’m constantly doing bulk operations on the data for one reason or another.

What I don’t understand is how frequently the app experiences errors like “app is too busy” and just completely gives up on my operation, or completely bungles a “create a list of things” operation.

For example, I run a workflow on 20 items that creates a list of 8 things to associate to these items. That’s a total of 160 things created. Each of the 20 items should have 8 new things associated at the end of this workflow.

Often, when I check the results of such an operation, it just didn’t work right. Sometimes it creates 16 things for an item, or 8 + a few duplicates. Or it stops halfway through. Or it just skips over it completely for other items. The result is complete chaos.

Am I crazy, or is this a really serious problem with Bubble? I’ve seen several threads hint at similar issues and the answer is usually just to space out the workflow more. Why can’t Bubble rate limit itself so that it delivers a dependable result?

A) Increased capacity may help.
B) Have more delay between your action when you schedule on a list. A lot of time, the delay is too small, you reach the max capacity and problems start.
C) Use Data API to bulk create. But again, you may reach max capacity of your app.

Are you using recursive workflows or are you using an API on a list / other out the box workflows?

I found recursive approaches both faster and more reliable for bulk operations.

1 Like

I forget this option. D) use recursive (loop) instead os schedule on a list. More reliable but slower sometimes.

Can you describe a recursive/loop workflow? I’m assuming you’re talking about something running on the user end rather than backend. Many of these operations have to be API operations because they’re not happening when a user is involved.

My question is less about how we get around these limits—it’s why Bubble has trouble keeping track of these operations. Capacity limits aside, in what world is it ok that a workflow would run itself twice and duplicate results? That’s just not normal.

I just ran a simple test where I have a repeating group of a data type called “Outfit Images”. On each cell I have a button that schedules a workflow on that cell’s outfit image. The workflow takes the image, grabs some info from it, and uses that info to generate a list of a new data type called “Outfit Pieces”.

As each piece is created, it’s added to a list of Outfit Pieces as a custom field on the Image.

Simple enough.

What happens is that if I click on one button, then click on another button while the first API workflow is still processing, weird things start to happen. The first one creates a few duplicate pieces, for example.

It’s completely unclear to me why two unrelated API workflows break each other. Is there a race condition of some sort here? If you’re creating the same type of item at the same time with two different flows, is there a chance the wires can get crossed?

No, these would be exclusively on your backend with no dependencies on the front.
Working recursively helps you control for race conditions as you can establish when one set of processes has completed before setting off another.
There’s quite a few forum threads out there on them plus a detailed guide here detailed guide.

1 Like