Is Bubble consistently unreliable?

9/11/18
For all practical purposes, this topic should be closed. I learned a lot from the discussion and appreciate everyone’s input. Some of the things I struggled with in the app were too interrelated to gain a clear understanding of. I am completely reworking the page, and some of the app.

In this discussion, I went off the rails more than once and for that I apologize.

Thanks to all who chimed in to help.


First post 9/5/18:
I am dealing with some very odd behavior that suggests Bubble cannot be relied upon to do the right thing or report that it has a problem that prevents it from doing the right thing.

Summary:

The program is a simple project/task management system. Its focus is on Actions. Each one is associated with a Project. It is a one-to-many relationship of Projects to Actions.

Because Actions will be updated under a variety of conditions, and referential integrity between Action and Project must be maintained, the logic to updated Action and its related Project is in a custom workflow, Update Action Detail. When it runs to completion, it seems to work as intended. However, it only runs to completion in one of two scenarios written so far.

Below is the event log from two scenarios.

First, the save button, btnSave, is clicked. The log is written as expected in every respect, comprising the first nine log entries.

Next, the Action’s status is changed to Done (dropStatusCode’s value is changed). Before triggering the custom workflow, the "is changed" workflow does some work to set custom states representing when the Action was completed, duration of work, and other values related to the "done" status.

As with the "btnSave is clicked" workflow, the dropStatusCode workflow should generate nine log entries. Instead, it unceremoniously ends when it should be doing the Make changes to Action step. Bubble gives no notification of a problem. It just stops executing. It is not stalled. The page is available and changes can be made. It just doesn’t finish the workflow.

The Update Action Detail workflow doesn’t do a lot of work. Of 15 steps, only five are doing any real work. Five are writing log entries and five are pausing in the vain hope that a short pause will clear things up and the thing won’t end prematurely. One of the real work steps is triggering another workflow to set some custom states on the page. Nothing really exotic is being done.

Why would Bubble fail to complete any workflow without throwing an error?

What should I be looking at as a possible cause of the problem?

BTW, just to see what might happen, I modified the "dropStatusCode is changed" workflow to not trigger Update Action Detail. I tested this, followed by clicking the Save button and it did what it was supposed to do. In essence, I manually did what "dropStatusCode is changed" should have done but with an intervening user action to click the Save button.

Sounds like some kind of a timing problem, but what am I looking for and why isn’t Bubble telling me there is a problem?

1 Like

Hi @laurence :slight_smile: I think this has to do with the way the workflows are set up. At first glance, the “add a pause before next action” only affects what’s happening on the page (such as animations) and doesn’t have an impact on server actions (actions that modify data). This is described in the documentation here:

Though it looks like the actions are happening one after the other, many or all are happening at the same time (unless a field is being changed and it’s using “Result of Step X…”). Can you share a link to your app’s editor? Or perhaps more screenshots of the Create a New Thing and Makes Changes to a Thing actions?

3 Likes

Seconding @fayewatson. As well, it seems like part (or most) of this could be moved to an API workflow. I’d recommend segmenting things out further.

As well, you are creating multiple of the same things (logs) within the same workflow. This seems like another great opportunity for an API workflow (on a list). You may be seeing an error because you’re adding several new things to the same table at the same time, but contained within the same workflow.

3 Likes

Indeed, and one that has not really been answered by the team. It just stops as you have found.

No, that is exactly the way Bubble is currently working. You cannot rely on workflows completing.

It appears to be an issue with record contention (what we used to call a “two dogs” situation back in the DB2 days) not being handled.

I have seen this several times when you want to create x things and update a particular thing to add each one to the list.

As above, moving to an API workflow is the answer, but it fundamentally won’t cure the issue. What you need to do is space the API workflows out sufficiently to prevent contention. A few seconds should do the trick.

It is on the Roadmap to be fixed, and that can’t come soon enough.

This …

…looks like it might be the start of it :+1::+1:

6 Likes

Thanks, Faye.

After nearly a year of working with Bubble off and on, I still have no concept of what is happening on the server and what is happening on the client.

At some point, it was recommended to me to use pauses to ensure that record updates were being completed and available in later steps. So, without knowing why or what the impact would be, I got into the habit of adding pauses whenever things didn’t seem to be updating properly.

I’m still fumbling around in the dark, but I am uncovering real flaws in Bubble and it’s incredibly frustrating. The app I’m developing isn’t even sophisticated. It should be, but I can’t even get a simply page with one-to-many referential integrity to work reliably and with reasonable responsiveness.

@NigelG has basically confirmed that some of what I’m experiencing are known flaws in Bubble.

The plethora of writing to a log table is a blind attempt to figure out where problems are occurring and what is causing sluggishness. Of course writing to a log is adding to sluggishness but I don’t know what else to do to get some idea of what’s happening under the covers.

I’ve read the documentation, including the reference you provided, but it’s still a mystery to me what is happening where. I don’t understand the value of API workflows as suggested by @dan1, especially since I am expecting a highly responsive user experience. Offloading work to the server asynchronously that should be immediately available to the user doesn’t seem like a good idea.

At this point I’m frustrated and pretty clueless. I knew how to build a great UI/UX in a client-server architecture. I am lost in this Bubble/AWS environment.

1 Like

@laurence some more options to explore …

Did you check the server logs?

Do you have any general workflow error handling in place?

What happens if you remove the pauses from (a copy of) the custom event workflow?

Does “Make changes to Action” refer to a previously set value of the action, making it dependent on a prior step/ the same step previously called?

1 Like

This is the same situation I have. It hasn’t been app killing for me, but it definitely something I need to start designing around

Thanks for your thoughts, mishav.

This all feels like it’s completely opposed to the promise of developing apps without code.

This is what Bubble promises:

Reality is completely the opposite when simple database updates cannot be handled properly by Bubble and I, the non-engineer, am guided to server logs and “trying” this or that with no specifics about what is really happening under the covers or why a change like removing pauses or implementing API workflows might have any benefit.

“don’t need to be a coder”? It’s harder than coding to work in Bubble. You need to think like a coder, learn to read server logs and somehow “try” making changes that might eliminate symptoms without really knowing what is happening.

At this point, as far as I can tell, I’d be better off becoming an engineer again and writing code so I know what’s really happening in my programs.

@emmanuel, please chime in. For what should be a relatively simple app, solving a basic, real-world problem, Bubble is completely falling down on the job. And the very sincere and helpful people in this forum seem to be grasping at straws in vain efforts to troubleshoot problems like I have been experiencing. I believe you and @josh had something better in mind, but my experience with Bubble, “without having to write code”, suggests the fundamental underpinnings of Bubble (AWS?) may be flawed.

2 Likes

Steven,

It is a sad thing when we have to design around flaws in the software development/hosting environment we chose because it was promoted as being easy and more fun than writing database routines (something I read in one of Bubble’s marketing messages.)

I’d rather be writing database routines I can trust than design (shadow boxing in the fog) around platform flaws.

Unfortunate consequence of using a something you don’t have absolute control over every part of. I don’t expect perfection and it’s good to see @emmanuel and @josh making progress on this. It’s first on the roadmap. https://bubble.io/roadmap I trust they’ll figure out solutions for these issues.

Hi Laurence,

Sorry you’re having some issues with your workflows. It is a bit hard to give feedback on how you’ve set up your app, not knowing exactly what you’re trying to do, and as Bubble is very open ended, one goal can be achieved in different ways, and not all are good. At first sight though, @fayewatson is right, you should only use pause actions for front-end effects, not in workflows that create or modify data (and if you do, as stated in the reference, these pauses aren’t applied).

In general, workflow execution is guaranteed to work. We do have one limitation currently around concurrent workflows touching the same data (though I don’t think it’s your problem here). It’s on the roadmap to fix (see “Workflow consistency guarantees”). So if you see some actions that aren’t run, the way to debug it is by using the debugger and the workflow logs. Bubble being a visual programming language to build software without writing code doesn’t mean that 1) you will always have it right from the beginning 2) you will not need to debug your workflows with the debugger and logs (among other things).

So I wouldn’t phrase it as “you need to think like a coder”, but more as you do need to think like a “programmer”, even if it’s without code. That’s what we mean when we say Bubble is a programming tool (even if it’s code-free). I understand this can be hard at time, and if there are features we can add to the debugger and the logs to make them easier to understand please let us know.

In this particular case, we’re happy to help you understand why the workflows don’t do what you expect them to do (in this thread). I would recommend starting by simplifying them (for instance by removing the pause actions) and then show more of your app (maybe make it public?) so that others can see what you’re trying to do.

7 Likes

Adding to this point, I’d recommend creating a small app, recreate a subset of your data structure, data rows, page design and workflow steps, just enough to reproduce the problem.

Then share the app editor and allow others to edit … duplicate the page for alternative approaches.

It may only cost you half an hour’s work, and the pluses are:

  • You may discover a solution while doing so.
  • You may find the problem isn’t reproducible, in which case it strengthens a bug report for your original app.
  • Allows the community to experiment, using solutions we have discovered with the effects you want to achieve.
4 Likes

My app has been throwing random errors all day, the console editor keeps crashing, and now i have this

{“message”:“Operation timed out – app too busy”,“statusCode”:400} and no app editor. UGGGGGGG!!!

https://status.bubble.is/

Thanks for replying, Emmanuel.

I’ll work on creating a test app. Hopefully, I’ll have something to share this weekend. My biggest concern here is that I don’t know what the problem is, therefore I don’t know what I can leave out of the test app and still produce the problem conditions. (There are more problems than the first scenario that started this thread.)

Distinguishing between coding and programming is splitting hairs. You’re absolutely right, you must think like a programmer with Bubble. In essence, though, Bubble uses code. It is confined to dialog boxes and text elements but the code is there nonetheless. Bubble may help you fill in the blanks, but it is still formulating code that will be interpreted at run time.

This:

image

is essentially this code:

If Current Page Action’s Project is empty and Current Page Action’s ProjectName is not empty then

Call Link Project Name to Project (Current Page Action)

end if

That could just as easily have been this:

If CurrentPageAction.Project = “” and CurrentPageAction.ProjectName <> “”,
LinkProjectNameToProject(CurrentPage.Action);

or any of a myriad of syntax design choices.

The difference is that it’s actually much easier to read the code than pick your way through a bunch of boxes to see what the code actually says.

In my simple app, having worked with a fair number of workflows in my attempt to structure the page functionality, I’m convinced that seeing the code would be easier than having it contained in dialog boxes inside of workflow boxes.

BTW, thank you for sorting the custom workflows alphabetically. It’s much easier to find what I’m looking for now.

Where/how would you like me to communicate suggestions for improvements to the debugger?

Ryan,

I’ve had sporadic problems today over and above the one that initiated this thread. UGGGGGGG indeed.

Dan,

I’m not clear what value an API workflow would provide in this case. What the app needs to do is provide quick response to the user, reflecting DB updates that maintain relational integrity.

All of the logging and pausing was added to try getting around other problems with accurately showing the user what DB updates were done.

I believe that Bubble has got their marketing slightly askew. I used to teach people how to use Bubble and I would get people come along that thought from the Bubble ‘don’t have to be a coder’ marketing, that it was another Wix!

In the end I had to change my own marketing to let them know Bubble was for people with front end development experience as a bare minimum who wanted to build complex web applications.

I believe that if the reference section was actually written for people without coding experience then yes, their marketing could be reduced down to ‘don’t need to be a coder’. But their reference material is not - it’s written by full-stack developers and they don’t realise how difficult much of it is to understand, especially without screenshots and real world examples. (Improving it is on their roadmap).

@emmanuel @josh I wish the Bubble team would correct their marketing while we wait for the Reference section to be written for the no-coder market. For now, most of us need to be full-stack developers to understand the reference/manual section, and the ‘don’t need to be a coder’ marketing is not true. Much as we love Bubble to bits and love the speed you can build an app, you often feel you’ve been drawn into a lie with the marketing.

2 Likes

An API workflow moves tasks from the user perspective (in front of them in their browser) to the background (on the server).

Generally speaking, when you have a large number of things happening, it’s better to move this to the server. Doing so ensures that a page change mid workflow (or reset popup, group or inputs), doesn’t break the workflow.

Additionally, you can create things in advance of when they are needed. (Ie. since you are creating a static number of new “Logs”, it would be feasible to “create” these earlier. Then, when you’re running the actual workflow above, you only use a “Make changes to a thing” action. (Then, you’re only making changes - which I believe happens faster for Bubble than a simple update to an existing thing so long as you’re directly referencing the “Log” to be updated).

Another thing I noticed in your workflow is that you’re triggering another Custom workflow (Set Reference Values) inside of a Custom workflow. This is something I would avoid. (Imagine you’re at a grocery store and need items from the dairy department, the produce department and the meat department. Triggering multiple workflows at the same time is like trying to fetch things from all three departments at once - something is bound to fall out of the cart).

1 Like

Although it may very well be that the known issues (multiple updates to the same thing) are not your issues.

It is difficult to tell from what you have written above. Maybe start another thread and split out the frustration from the issue resolution.

And I KNOW how frustrating it can be !

1 Like