This is simply maddening. It would be so helpful if workflows would just run the steps prescribed in the order in which they were prescribed.
I have a process that is updating a parent record and children records with a delete flag= Yes so that I can run a scheduled workflow later. How hard could it be, right?
When I run this workflow at normal speed, it appear to hang as the group loader is never dismissed. I also never see a progress bar at the top of the screen.
If I run it in the debugger at slow or step by step, it works fine.
Yes, I could use Parent Group’s Project instead of a search for the Project in the Project step update except it never works. The database never shows an update.
So, this must be a race condition of some sort.
I’m running out of hair trying to figure out this one out. I mean this is to update two records. Any ideas?
Any “Terminate workflow” acted as a buffer (just put a false condition), and all parallel javascript process will stop there and then, continue. With the use of Only When for sure, you will have you serial sequence. I also use the plugin WAIT server side/client side to help.
The debugger is in serial mode, not parallel mode.
Ok that seems to help but only on the second time I execute it. The first time I run it after refreshing the page, it does nothing. The second time I click it, it works perfectly.
Now I’m really perplexed! Thanks @JohnMark for the pointers.
I’m glad this has been of service. I’ve been able to move all but one update process to database trigger workflows. Unfortunately the one that remains is the one not triggering on the first attempt.
I came here for hot dog fingers. Was disappointed. Lemme fix that.
@treb.gatte I would hate for you to lose any more hair. I’ve shed my share when dealing with race conditions.
My hunch is that step 5 is the culprit. I’ve essentially black-listed make a change to a list of things from my apps. I only use recurring workflows. If I were you, I would:
I had a long talk with Bubble Support and there are three changes we made that resolved this problem.
First, I stopped using the Confirmation prompt from the @copilot Browser plugin as it was causing this weird delay in execution. This is why updating a record was taking forever and other actions were running immediately. I found it by accident when I inadvertently dragged the delete a thing step in front of the prompt step and it ran instantaneously.
So, I created a Bubble popup for the confirm and good to go. I’m still using the Browser plugin for other items.
Second, Support had me create a custom event for the first delete and then trigger the custom event from the main workflow. This ensures it runs when you want it.
Third, I moved the rest of the delete process to a backend workflow that is triggered when the first table is updated.
Once I did all of this, it worked perfectly and the performance is really, really good.
So basically, I did most of what you suggested already. I simply hadn’t had the chance to get back to update this.
We haven’t received any reports with execution threads concerning the confirmation action with the Browser plugin. We’ll definitely reach out to get some more information!
Great to hear you were able to find a resolution to your original question! I was going to chime in with some suggestions on re-organizing the workflow a little but glad our success team got to it first. This is a great example of an opportunity on our end to teach better practices around workflow logic.
Let me give you the rest of the story.