Ok test done, it doesn’t work.
What I think happens is that step 2 is executed after step 1, true.
But too fast, and since step 1 is longer to execute, step 2 is solved before that the database is modified.
The problem here is that I know that a field in the database will be modified as I expect; what I want the app to do is waiting long enough to find that field modified.
Kind of “enter the room as soon as the light will be switched on”.
You mean that having Step 2 to needing input from Step 1 did not make Step 2 wait? That would have some serious effects.
I also tried on one of my projects, much more complex than the simple example I created for this topic, and actually the only solution that always works, so far, in number 3 (the ping-pong technique).
I agree that the effects are serious and have to be kept in mind.
As @aschofer wrote:
Frontend workflow actions run in order but the next action does not wait on the previous action to be complete before triggering
This means that some more time consuming actions (database manipulations, conditional actions with a search with filters, backend workflows), even if triggered before will end much later than a simple action such a custom state set value (they actually do).
It’s also well-described in the documentation.
SOLUTION 1 looks like the right solution to me IF, as @philledille says, step 2 references step 1 (makes it a dependency). That’s the way Bubble should work and the way it has worked for me.
If you have a reproducible example where that’s not the case, you should file a bug report. You shouldn’t have to jump through hoops to accomplish what you’re trying to do.
thank you for taking the time to reply to my post.
Well I don’t really think this behaviour is a bug, rather something (annoying) to keep in mind.
All the 5 workarounds suggested in the documentation are, really, workarounds. Also what I called the “ping-pong” technique is a (painful but not impossible) workaround.
Thinking that the “Result of step X” operator creates a dependency, as far as I understand, is a mistake: it doesn’t mean “wait for previous step to be finished”, but rather “take the values I sent to the database directly from the previous step without the need to search the database [that will be updates asap, but maybe later than you expect]”.
This makes a huge difference, especially if what you are interested in is not the data passed to the database, but a condition that becomes true when that database record is modified.
2 things to keep in mind:
That’s what database triggers are for.
Bubble is event driven and has a “reactive” front end baked into the platform; so depending on the problem you’re trying to solve, you might not need to set a state at all. Data that’s dynamically referenced in the UI (from the front end), for instance, will automatically update when the underlying value changes. (It’s not uncommon for folks with a bit of traditional coding background to approach Bubble with more of a “procedural” mentality and thus try to “force” execution order or use workflows when it’s not really necessary.)
Another way is to use Terminate with a condition, since the actions after the Terminate don’t know if they should be executed or not until the Terminate’s condition is resolved.
Maybe it’s me missing something, and I’ll be happy to learn from this discussion.
There are 2 important statements taken from the documentation:
Searches aren’t always immediately updated with new data. So if you create a new item, and then try to retrieve it via search, it may or may not work; you should not rely on this.
We do not offer the explicit ability for an action to wait for a workflow to be over before moving on to the next step; however, using ‘add a pause before next action’ action is usually an effective workaround
Sometimes I see conditions considered as a way to put an action on hold until the condition is met. As far as I understand the truth is that things will happen without delay either way, the only difference being the fact that the action has been executed or not.
Statement A always has to be kept in mind, in my experience especially as single page apps grow: this is when I think the app itself can become slower and record changes experience delays.
Statement B is clear enough: a delay is not possible out of the box. A simple workaround is waiting a fixed amount of time, but this is not enough if you want to be 100% sure that things happen the right way (it’s not a “wait until…”
Hence the “ping-pong” solution.
I’m also testing
Trigger a custom event when data changes: no luck so far;
WF with Do when condition is true trigger: under testing, fingers crossed.
This will either (1) stop the workflow or (2) continue its execution (without waiting for the condition to be true).
In case (1) nothing happens, but since in my case the WF is triggered by a button that registers to the database the value of an input field, the client doesn’t see anything happening. And this is not acceptable.
In case (2) things will happen, perfect: it means that the control database record has been updated BEFORE the execution of the terminate action.
This solution appears to be working. This is good news indeed.
The truth is that we [nocoders with average experience, I’m not talking of gurus] have to consider all of this or some functionalities of our apps won’t work properly.
I’ve just checked the documentation about workflows, and I found this workaround:
In a workflow with two actions, if Step 2 is using a condition based on a search depending on data manipulated in Step 1, then Step 1 should be implemented into a custom event to make sure it is finished before moving on to Step 2.
This way you’re sure the changes have made before used them in a custom state.
That means solution 2 from @aschofer is right
Hope this helps
believe me or not, but this was the first solution I tried and, in my app, didn’t work as expected.
I’ll reset all the workflows and start from scratch, maybe after too many corrections something under the hood is wrong and prevents things to work properly.
I’ll post something ASAP.
@gallahad11 I’ve just checked your app and I don’t understand what value you want to pass to custom state (as shown below)
What’s “amount - deleted” ? There is no corresponding field in a DB.
my fault, during this discussion I modified the app, deleted fields and unfortunately now is not working. I’ll do my best to correct this in the next minutes.
ok it’s at its original state. Sorry again for making you lose time.
@gallahad11, I tested your app with the debugger and all work well
It seems solution 3 is the faster following by second one.
@mickceb did you try:
- refresh page
- click trigger1
- click button reset
- click trigger1
the second time you click the trigger1 button, do you see the active text appearing? (I don’t)
I clicked button and reset multiple times and each time “active” appears.
Have you tried with another device?
I tried on my mac (chrome and Safari) and on the iphone. Same behaviour.
I also tested the test app with debugger set to SLOW.
As expected it works perfectly, all 3 solutions.: slowing the process I think that all the actions are executed in the proper order, without client side machine speed overtaking server side actions.
IE: it’s a matter of speed and timing.
If the computer is powerful all the client side actions will happen quickly and chances are that they will generate outputs faster than server side actions (involving calls to DB).
According to Bubble guidelines SOLUTION 2 should work, but doesn’t.
Another interesting statement in the document is:
Custom events run in sequence, not parallel [ok, no problem understanding this]. If Workflow 1 triggers a custom event that starts Workflow 2, Workflow 2 will complete before the remaining actions in Workflow 1 run.
I get confused by the second part: as far as I know a workflow can start an API workflow or a custom event.
If everything stays client side I could interpret the statement as: If Workflow 1 triggers a custom event that starts CUSTOM EVENT 2, CUSTOM EVENT 2 will complete before the remaining actions in Workflow 1 run.
But actually this is not true.
I’ll ask Bubble support to examine the case and hopefully get to understand a little more.
A couple of weeks passed since the last post, thus a little update.
I put the test app offline since its behaviour changed. I think this statement recently found on the official bubble docs is connected (I’m pretty sure it’s been recently added):
Tip: If an end-user does something that kicks off the same workflow many times within a short window of time (e.g. clicking on a button repeatedly very quickly), Bubble tries to be smart about executing that workflow: any actions that make sense to repeat (e.g. changing a thing) will be repeated and any actions that don’t make sense to repeat (e.g. navigating to another page) should not be repeated.
A lot has been written in this forum about sequence in workflows, I suggest reading this post to understand a little more about what is triggered before (and actually yes, it’s API workflows) and what after.
The use of custom events is fundamental to control order of execution.
But another thing has to be kept in mind, taken from this post of @keith :
… Bubble has kind of an interesting optimization around database operations. When you “Create a New Thing”, the unique ID of the Thing is created client side and the values of the fields of the Thing actually do exist for that user’s session . However, the actual creation of the Things (back on the server) might be substantially delayed.
Here’s why “result of step X” is generally safe. But be careful that it doesn’t represent the modified underlying DB value, that could (and generally will be) updated later.
With so many constraint to consider, my conclusion is that the best way of organising complex workflows (ie with API calls, changes to DB, custom events) is using custom events and “do when condition is true” (as also Bubble support suggested me after being asked).