WU spike - 12,600 RG searches from 1 user in 25 minutes

building4stripe · 2024-12-07T02:57:10.158Z

Hi all, I’ve been experiencing a crazy WU spike in the past hour, spending 15,000 WU in about 25 minutes. At first, I thought it had to be a recursive workflow that’s gone haywire, but looking through the logs and app metrics, it turns out that wasn’t the issue.

All of the WU were spent on a single RG that was fetching data constantly. 12600 searches in 25 minutes, from a single browser (I’m the only one with access to this development branch and the RG is not live in any other branch). The moment I refreshed my browser window, the searches and WU seized.

Screenshot 2024-12-06 at 6.42.30 PM2242×1760 365 KB

The RG that was causing the spike was fetching data from another RG that is getting data from a very simple search, just two parameters, and there are less than 50 entries in the development database.

Screenshot 2024-12-06 at 6.44.22 PM682×846 46.1 KB

Screenshot 2024-12-06 at 6.44.55 PM668×762 31.9 KB

After seeing this spike, I started reviewing our logs in the live branch which has a good amount of monthly users (around 500), and noticed that a similar spike occurred in the live branch overnight. The spike went on for about 10 minutes and it was fetching data from a simple search query (also 2 parameters as you can see below). This spike went on for about 10 minutes, ending the same minute as a specific user was last active (we’re tracking when users are active using a recurring workflow that updates the user’s ‘last active’ field every 60 seconds).

Screenshot 2024-12-06 at 6.53.01 PM682×1028 46.4 KB

Screenshot 2024-12-06 at 6.54.03 PM1572×1008 101 KB

It looks like the one overnight was our first ever significant spike not caused by expected increase in visits over a short period of time due to ads. Has anyone else experienced these types og spikes before (caused by fetching data in an RG)?

fede.bubble · 2024-12-07T02:58:08.199Z

have you tried connecting with support about this?

bubble.io

Bubble Support Center

building4stripe · 2024-12-07T02:59:48.838Z

Yes, messaged them just now

georgecollier · 2024-12-07T03:05:21.587Z

Do you have some logic (e.g workflows) set up in your app that would cause the constraints (or the values of the constraints) to change recursively, triggering a new search lots of times per second?

building4stripe · 2024-12-07T03:12:44.139Z

The live spike overnight was in an RG with very simple notifications. They are only edited through a single workflow which is the one marking the notification as seen. That RG’s been live in its current form for about a year, without any changes, and this is the first spike resulting from data fetching. The one that just occurred in the development branch is for a data type that is edited frequently, but the constraints in the search query rarely changes.

georgecollier · 2024-12-07T03:18:35.796Z

Do you happen to be using the HeroIcons plugin?

building4stripe · 2024-12-07T03:20:55.851Z

Nope, not using that one

johnny · 2024-12-07T07:47:07.699Z

Are you using any visual element plugin in a repeating group that isn’t a native Bubble element? Or any hidden repeating groups? It’s hard to say exactly what might be causing it without looking under the hood in the editor

boston85719 · 2024-12-07T07:59:04.475Z

did you leave your browser open overnight?

ihsanzainal84 · 2024-12-07T14:19:38.969Z

Here’s my theory.

It looks to me that the expected results of the Search is large. So while the initial search might return a few, whenever your other RG has to do a sort (based of that dynamic field), it will cause the search to run again to ensure that the sort is maintained. Whether it’s a bug or as intended, only Bubble will know.

Why not store your search in a state list first, and then refer to that state for your dynamic sorting.

building4stripe · 2024-12-07T21:40:56.198Z

There are no other references to the RG than a table that is filtering results dynamically (no charts etc.)

building4stripe · 2024-12-07T21:42:41.937Z

When I think about it, yes I probably did, but I was developing less than an hour before the spike occurred. I had certainly refreshed the browser less than 1.5hrs before the dev branch spike.

building4stripe · 2024-12-07T21:46:40.401Z

If that was indeed the case, I would expect to bave seen this issue before, but it’s the first time and we’ve used this setup across the platform for about two years. The spike in the live branch was in an RG that’s remained unedited since early-2023. Either way, I can’t imagine it being anything other than a bug. I mean, an average of 8 identical searches per second for 25 minutes…

On the suggestion about using states, we’re doing this in some places, but only for data types that don’t need to stream in and stay updated. Appreciate the suggestion though, might go for that as a temporary measure until Bubble responds.

boston85719 · 2024-12-08T05:41:27.635Z

It’s likely the reason since your RG is populated by a data type you say is edited frequently…if it’s not leaving the browser open that did it, it’s a bug, but I think it’s the browser left open and the data type getting edited frequently

prograds · 2025-01-29T00:34:56.175Z

It’s exactly this kind of spike that I’ve been contacting support about over the last year. For me it’s not coming up as RG searches, it’s just “individual data request”.

Look at my latest example.
No usage/execution between 14:09 and 15:40 in the log.
Then look at the timing of the spike. Crazy!

Untitled2304×1440 65.3 KB

image975×872 87.3 KB

image975×872 87.3 KB

And then it just stops at like 16:10 (not shown).

As with others, this is so strangely intermittent and without any new deployment and with no obvious change in user activity.

sem · 2025-01-29T07:09:24.560Z

Perhaps Bubble is running some cron jobs on all apps with regular intervals and those WU are added to the customer account

building4stripe · 2025-01-29T10:27:47.049Z

Both sorry you’re experiencing the same issue and glad I can confirm others are too. I received a response from Bubble Support after about 4 weeks. At that point, data about what caused the spike had already expired and been deleted, so there was essentially no help at all. I’ve experienced the spike once more after this post, and that was in late December.

Let’s continue to report the bug, and hopefully they’ll eventually be able to identify the issue. I’m linking to this forum post in the bug report.

building4stripe · 2025-01-29T10:30:41.900Z

Haha, I hope not (and don’t believe they are). They ignored my request for them to reimburse the cost for the overages. Should have pressed the issue, but didn’t.

system · 2025-02-15T02:57:45.160Z

This topic was automatically closed after 70 days. New replies are no longer allowed.