Appreciate the response. Support was also unable to help here, but I believe I’ve just figured it out using chained return values from various custom events to ensure completion of the prior event before starting the next event. I can now ensure sequential work where I need it.
I would have loved to share more info, especially since I was asking the community for help, but my app does significant revenue in a highly competitive space, and I am extremely protective of it.
I have also been having this issue. I have found that if you use schedule a custom event with a 0 second delay instead of using trigger custom event, the workflow normally runs properly in order.
I have no idea why this is the case and I spent hours trying to solve this.
Interesting, thanks. I am going to play around with this. I would be surprised for me if it worked because I have needed to space mine out with at least .3 seconds of delay.
I have continued to work on this regularly with support and they basically confirmed as of last week that this is broken (my words/my opinion). Below is the last pertinent correspondence.
From Bubble Support:
"I’ve received word that this behavior you’re experiencing is related to an edge case of our workflow logic, where if a workflow has a mix of actions that happen on both the client and server, the ordering of the actions fired might be different from the linear design because of what’s firing on the client versus the server. For context, what seems to be happening here is that both the “create” and “make changes to” actions are ones that run on both the client and server. As a result, these actions, along with their associated custom events, may execute of out sequence.
We mitigate behaviors like this to some extent with some very complex logic, but in our current architecture, some occurrences of this may still slip through, and we don’t have a quick fix to provide at the moment. I understand that you’d like to refrain from relying on scheduled triggers, but it’s my understanding that this is the most reliable workaround for this this known limitation. I sincerely apologize for the inconvenience this has caused, but I hope this explanation helps clarify this behavior you’ve encountered."
My response:
"Thanks for your work on this and given my understanding of the workflow logic I did know that some of this was possible. I guess where I’m confused though, is that these items, especially on the simplified test case we created yesterday, do not have any client side actions. More so, the conditionals should always be accurate, no? And also, as part of the same workflow logic you mentioned, custom events should execute in order.
I understand your explanation but really don’t think it matches here. It feels like a bug to me."
From Bubble Support:
"I wanted to let you know that I’ve shared the test case with one of our engineers, and they confirmed that the “create” and “make changes to” actions will need to run on both the server and client. It’s important to note that with workflows, there’s often a lot going on behind-the-scenes during execution, and some actions that seem strictly server-side actually need to run on the client as well.
This means that when working with these actions, the order in which they are triggered can sometimes deviate from the linear design, even when triggering the actions in a separate custom event."
I confirmed this is also 50/50 hit or miss when running only as a backend workflow, so again in my opinion, this is simply broken.
My other previous replies to this thread regarding custom event return values stopped working so I am back to scheduling these with a delay instead of triggering them in order as I desire.
In quick testing it does appear scheduling with a 0 second delay is working for me. I’ll need to do more testing as I have definitely seen issues with scheduling things with a .1 or .2 second delay vs. a .3 or .4 second delay specific to creation/changing of DB items.
Spoke too soon. I was able to recreate duplicate DB item creation using schedule with 0 second delay.
I think the solution is simple. In the main workflow, when any custom events are triggered, pass all the data required for that event to work as parameter itself. Meaning, don’t let the custom event access any of your page fields’ directly. Seems to me, that’s what breaks the sequential flow.
Ever since I fixed this, things started working fine for me!
Mind supplying a screenshot showing this? I’m not 100% following and I believe I tried every variation of this (and support confirmed the behavior I was seeing).
For example, here, I have a Stock Table containing a list of ‘Line Items’. When I want to create a new Line Item, I check whether it already doesn’t exist in the Stock Table. If it doesn’t exist, the new Line Item is created. But if it does exist, an error message is shown and line item isn’t created.
Case 1: Now, when I was accessing the data from the page’s fields directly, like so,
Whenever an item already existed it worked fine, gave an error alert and exited. But, when the item didn’t exist, even though the new Line Item was created, it showed the error alert instead of Success alert.
Case 2: Now, instead of accessing the fields on the page directly, in the middle of workflow execution, when I saved the data from the fields, and then passed the necessary arguments to the backend events/workflows as parameters, like so,
The whole problem from case 1 disappeared. And as with this workflow, there were atleast 3 other workflows in my app that faced similar execution problems. And when I stopped accessing the fields from the page directly from the backend, in the middle of workflow execution, things started working just fine. So that’s that.
How is your dropdown setup? If it’s dynamic then I would assume whatever that is selected from that dropdown would already exist and hence throw an error.
Whereas passing a value from the original WF (which would be the right way of doing things, for what you are trying to do) will pass the correct value to the custom event.
