Please upvote backend WF error trigger

Idea
1

Dear Bubblers,
when one of the frequent problems in Bubble occur, a backend WF might be aborted whilst running.

For some apps, like mine, an incomplete backend WF generates huge problems. In my case it creates an inconsistent transaction that completely blocks my users until I manually fix it.

Unfortunately there is no “when an error occurs” on the backend and I learn of a problem just when a user contacts me to complain.

Please upvote this feature: workflow error trigger available in backend

If Bubble cannot become reliable in the short term, it should at least let us manage the problems it causes.

2 Likes
2

Errors should only really occur with external APIs or plugin actions. You can handle the first very easily by including errors in the API response (then Create a new Log (data type) when Result of step X’s returned an error is yes).

With plug-in actions, you can probably build an error detection or just use other relevant conditions to work out if an error has happened.

3

Hi, I experience errors in absence of external APIs or plugin actions.

  1. The user triggers a WF#1 in the frontend;
  2. A WF#2 in backend is fired completing a series of actions (without external APIs or plugins). I set this in the backend to smooth the user experience in the frontend.

It’s the WF#2 that may fail if in the meantime Bubble goes down. The problem is that WFs in the backend don’t have a “when an error occurs” so I cannot know when they fail.

4

I love Bubble but reliability is still something that appears very far. During the last week, my users suffered from 4 Bubble failures.

Besides situations where a user is simply prevented from using the app, there are others where something fails or takes too long on the backend generating errors that need to be fixed. For example this

In such cases:

  • I learn about the problem from my users (an not all them let me know);
  • I need to check logs via Bubble’s very painful interface (God knows how many hours I spent on that!)

While we look forward to a situation where Bubble becomes reliable, it would be useful to be notified of a backend error/timeout. At least I can trigger an email to myself and be aware of what exactly I need to fix.

Please upvote workflow error trigger available in backend.

Thx

2 Likes
5

Gian, I’m with you but you’re wasting your time. As it is, only a tiny fraction of Bubble apps have backend workflows, and the ones that do usually have a handful of simple processes or API calls. Even @georgecollier, based on his post above, seems not to have too many back-end WFs with complex series of actions.

If you search for issues related to race conditions or queues, the lack of discussion on the topics makes you think Bubble is built on a noSQL DB like Mongo. (I’ve also yet to find a queue dataset or anything similar in over 15k bubble DBs).

And clearly Bubble has decided its only chance of survival is as a front-end/mobile app setup (decided? :thinking: or perhaps created the situation with its whole WU costs shenanigans?) and certainly isn’t going to make any significant back-end updates other than those that close the loop on some of its ginormous tech debt (e.g., removing the old WF view).

Be that as it may, just like race conditions, the only way to build an error-proof back-end, given the server timeouts, outages, and random termination of WFs due to recursion (No Bubble, my hourly access token update from FedEx is not an infinite recurring WF!!, it’s an hourly call intentionally planned) is to build in queues or error checks on a series of conditions (and not hold your breath on Bubble creating a solution).

Thankfully, with custom events serving as global states, it’s a lot easier than it used to be.

The basic gist is to do the series of actions (“actions” you need without saving them to the DB (assuming you need prior data if there’s a failure within the actions) and then at the end of the actions, update the record and indicate that the actions successfully completed (very use case specific how you want to go about doing that, whether as a field or within a Q, etc).

Then, using a separate WF, either as part of a Q or just an error check for that single series of actions or an error check for an entire batch of actions (if Bubble goes down for a few mins+, the single error check will probably have been cancelled as it would have run in the past), check if the actions properly completed. If they did, then great, and if they didn’t, rerun the actions…

2 Likes
6

I’ve also used this strategy when facing recursive WF failing in the backend.

In particular, I schedule workflows solely dedicated to check the health of the process in question. They basically check the ID of the workflow of the process under monitoring. If it doesn’t change after a certain threshold, the process is dead and it’s rebooted.

2 Likes
7

Thank you. It’s very hard to understands how most of the apps can do without backend WFs. What do you mean with “with custom events serving as global states, it’s a lot easier than it used to be.”?
As far I know there aren’t custom states in the back end. I use List Popper and Friends (SSAs).
Am I missing a feature? Or maybe you were referring to custom states in the front-end?

In any case, my WFs in the backend are already very complex and consume a lot of WUs comparing to the number of paying users. Some of such backend WUs are run to make the front end lighter, some others are run while the user is not online (so there is no front end). Adding additional states just to check that the workflow completed would add complexity and additional WUs.
I’m convinced that the feature I’m asking would make things easier and Bubble a more valuable tool.

In alternative (or in addition) it would be useful if a backend WF could “return data” to the front end. Now it only returns the WF ID unless setting up a complex environment where my app appears as an external app.

Overall, you are right: Bubble doesn’t seem to care much about the topic…

8

@code-escapee said Custom Events (not Custom States)…

Custom Events can be used to define values on the backend, and are significantly faster and less costly in WU than using plugins like List Popper.

I used to use ListPopper a lot for backend variables, but after Bubble enabled return values from custom events, and after comparing performance and WU cost, I now only ever use Custom Events for working with backend variables.

But it’s still completely ridiculous that A. there is no built in way to define variables on the backend (in a platform that claims to be able to everything you can do in traditional code) without using workarounds like this, and B. that, even with this workaround, you still get charged WU basically every time you need to define a variable (even if it is a lot less costly using Custom Events than it is using plugins).

In alternative (or in addition) it would be useful if a backend WF could “return data” to the front end. Now it only returns the WF ID unless setting up a complex environment where my app appears as an external app.

It still baffling that this is not possible without resorting to unnecessary workarounds (and almost defeats the purpose of backend WFs) - despite having been requested for as long as I’ve been using Bubble (6 years+), they have no plans to add this functionality, so it seems.

3 Likes
9

When I do, they’re broken down into appropriate sizes. Pretty rare a backend workflow needs to be more than 10 actions.

No doubt. The reasoning for why this hasn’t been implemented is that it’s technically possible via API Connector and/or App Connector, but those limitations don’t gracefully handle data types and option sets and the whole feature seems like an easy (comparatively speaking) win…

1 Like
10

11m 35s

He gives a very bizarre answer. Apparently he thinks this would somehow compromise “page security” because people would use more backend workflows. This is despite the fact that there is no such thing as page security and backend workflows are way more secure.

1 Like
11

There is.

Among many other things, pages protected by server-side redirects will have all workflows fail if a user tries to execute them when they shouldn’t.

Backend workflows don’t have this level of protection, and I’ve seen very few people but permission-related conditions on backend workflows to protect them.

So, if synchronous backend workflows are implemented in their simple form, it could lead to users building in such a way that removes the protection that server-side redirects afford them.

Of course, that’s also the case in the current implementation of making backend workflows public and calling them from the front-end, but they clearly believe that integrating synchronous backend workflows could result in more people building in an insecure way.

I completely agree that they should prioritise it, just wanted to correct your assumption that there’s ‘no such thing as page security’, and ‘backend workflows are way more secure’ , because the former isn’t true, and the latter is only true when used correctly, which people aren’t very good at.

12

Either you have conditions protecting your workflows or you don’t, in which case this doesn’t matter (because they don’t need to use those workflows to get the desired effect of the workflows). So it’s a completely moot point.

13

No, a server-side redirect condition like ‘Current User’s Role is not Admin → Go to page’ acts as an invisible blank condition on all workflows on the page that will ensure they can only run when they’re an admin, even when they don’t have a condition.

14

What do workflows do?

15

There are certainly times when more than 10 actions are needed for complex workflows especially with handling rce conditions and looping.

Be that as it may, even if it’s 3 actions, if these actions are critical to the functioning of the app → an error check of sorts is needed. I have yet to see anything of the sort set up in any Bubble DB that I haven’t set up, and while I’m sure that there are such DBs, my point is its nowhere near a critical mass to get Bubble to deal with this issue, especially when they fighting to stay above water.

@gianluca1 (my brain isn’t working at this point of the day after 14 hours building, so this may be totally wrong) I don’t think Bubble can even solve the back end workflow error if Bubble wanted to cater to users like us(and ignoring the logistics of their crushing tech debt) as if/when Bubble has an outage, such WF errors wouldn’t be triggered, so for actually critical app data, you’d need my approach regardless. - Just a thought that might make it less annoying to build these error check workflows if they’d need to be built regardless… although, of course, if there weren’t outages regularly…

1 Like
16

Thanks