Infinite API Calls - But APIs Not Enabled

I have a very weird behavior right now. My site does not have Backend Workflows enabled (I turned them off), yet I’m still getting these requests every few seconds:

I received a message about workload spike from yesterday, and nothing I do can stop these requests from coming in. It’s a database trigger, but I can’t pinpoint the source. There are no other calls or page loads other than this API, which then calls the database trigger. Help! It doesn’t stop.

If you enable backend workflows, is there any API Workflows there that are allowed to run without authentication? Maybe one of them is being pinged even when backend WFs is technically disabled…

I checked that, none are enabled. The weird thing is, this is a Trigger on the backend workflow. Something is triggering it, but the logs don’t show any source?

If you enable all of the filters does it show anything else like inbound http requests?

Hopefully you can reach out to support and they will figure it out + reimburse you because this doesn’t look right…

Do you have the Data API enabled?

It was enabled, but I turned it off. I checked only for http requests and nothing shows there. Just the API Request being made over and over again.

Support it looking into it. Seems like a really weird bug.

I checked my logs and apparently it’s been going on for at least two weeks, just really spiked up the last two days for some reason. I’m so perplexed on this.

Just to add info, in case it helps someone in the future: The trigger that comes through is on my User table, but when I e-mail myself the info of the “User now”, there’s no e-mail address. I didn’t it was possible to create a user with no e-mail address? The only fields that are filled out have default values.

I’ll post the solution when we figure it out.

Technically the Admin user (admin API key or a database trigger which is admin privileges) is a real user but does not have an email address.

Good luck looks like a bad bug :face_with_spiral_eyes:

That’s interesting… Learned something new. Thanks for the response Tyler.

Looks like I’ve pinpointed the issue. It’s anonymous users that are causing a backend trigger to fire that is tied to the User table. This was really hard to diagnose. Apparently anonymous users still get default field values (which was one of my conditionals to check before running the trigger) and it kept firing this loop every few seconds.

Figured it out!

On that note…wow…who knew websites are getting hit every few seconds by bots.

2 Likes

I only realised this was happening in my apps a few weeks ago. Yeah, even logged out users have user triggers. If anything on their field changes, the trigger can be evaluated (and run if the condition is met).

Also, when calling a BEWF with an admin API token, sets off triggers User triggers too.

This was really frustrating, there should be a field for “anonymous user” or something to check. I’m surprised this issue hasn’t come up more often. Maybe others are better at reading documentation than I am!

Triggers are definitely a little unintuitive IMO, needs more buttons to just pick fields to “monitor” and like you found, maybe a checkbox to only run for logged in users. And list fields I still don’t think there’s a way to compare “List field before is not list field after” without resorting to turning the list into a list of UIDs then comparing those. Just general stuff to make it easier for no-coders

We encountered this a while ago - We had a service to periodically ping the site for uptime monitoring and this caused a DB trigger to be executed each time - quickly increasing the row count in the DB to about 800k irrelevant records.

Nice one on figuring this one out - Agree it’s not intuitive.

P.S: Fortunately, this was before WU was introduced.

1 Like

I’m slowly building my first Bubble app while I learn Bubble. I created my database first, am now working on the pages, and haven’t added any workflows yet. I had already decided to keep my User data type lean based on other forum discussions I’ve read, putting most entries in a separate Settings data type (locking down both with privacy rules). Now, based on this discussion, I think I’ll put everything in the Settings data type except the default fields in User. The Settings tab doesn’t get populated until the user signs up. Hopefully, I can prevent most of these kinds of situations this way. Crossing fingers…

I found another workaround in the Bubble documentation. This won’t be appropriate for all kinds of apps (for example, an online store where users can add items to a shopping cart before logging in), but there’s a setting that can be turned on: “Do not set cookies on new visitors by default.” This prevents temporary/anonymous users from being added to the Users data type.

My app doesn’t need to store any cookies until the user logs in or signs up, so I’m turning this setting on.

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