Hey all, we’re rolling out a bug fix that was leading to event conditions getting evaluated incorrectly in situations where there’s a delay updating the user’s web browser with the latest data from the server.
Unfortunately, fixing this means that we have to force a sync of data used in event conditions, which might introduce a brief delay where the loading bar becomes visible. In general this should be a very minor performance change, but in certain cases workflows that used to appear to run instantaneously may now have a visible delay.
This change does not affect action conditions, so if this impacts one of your workflows, you can remove the event condition and add it as an action condition.
Sorry about the change – shouldn’t have much of a visible impact (and the bug that it fixes is important to get fixed), but wanted to make you all aware in case you do have a situation where switching to an action condition makes a meaningful difference.
Hi @josh, maybe I’m stupid but can you give an example here as I’m not quite sure I understand. What has happened to incorrectly evaluated event conditions? What types specifically? It will be good to get a better understanding of impacted conditions so I can perhaps change to action conditions for these.
However, I do understand that this will slow the system down (even) more. I know you say it will be minor, but I have seen that seemingly minor changes have very big consequences down the road. (and with down the road I mean, locations further away from server or with average internet speeds)
Really hoping for some good news regarding server speeds soon
Thanks @josh. Can you please post to confirm when the bug fix is rolled out as I believe I am experiencing errors due to this bug in relation to state changes and conditional visibility only working intermittently.
Would you suggest we eliminate Event level Conditions when possible in favour of Action Level Conditions? Or is it more like Event Conditions are now "slowing down’ to the speed that Action level conditions are currently at?
A common example would be ‘On Page Load’ conditions. Is it better to combine them all into one ‘On Page Load’, or would likely be the same?
Eaxmple -
When Page is Loaded and Get “scroll” from URL is “faq”
-> Action - scroll to a group
When Page is Loaded and Current User’s Type is Admin
-> Action - show element
Would it be optimal to instead put a SINGLE When Page is Loaded
-> Action (with condition) - scroll to
-> Action (with condition) - show element
The bug fix is currently live. An example of how it could have caused issues:
Suppose you have a workflow with event “When a user clicks a button, and the current user’s name is Joe” and action “Send an email saying ‘Hi Joe’”.
If the user opened two different web browsers, and in browser 1, changed his name from Joe -> Sam, there might have been a period of time where in browser 2, you could still click the button and have the “Hi Joe” email get sent out.
No, I only suggest changing this if you are specifically observing a particular workflow that used to run instantly as of this morning that now has a delay, and that delay makes a big difference to your application. If you didn’t notice a difference from this fix, I wouldn’t recommend changing things around.
Thanks!! This is going to make a huge difference in our application. It continues to move Bubble in the right direction and makes it ever more reliable and valuable. Keep up the good work!!
This is a classic use to filter a RG on a list of items. Currently the Event has a condition to run the action based on if the status contains the filter term yes or no. The other event condition runs if the list is empty, so it adds the term.
If I put them both in the same action with no event condition and only add action conditions, they run right after each other and the last action cancels out the first.
Is there a way around this? I have a lot of event conditions and I don’t think they can all be replaced by Action conditions?
Thanks for the feedback. I’m releasing a change in the next hour or so that should help: workflows that don’t modify data on the server or take any server actions don’t need to be synced with the server, so I’ll exclude them from the fix we just did. In this case, since all your workflows are doing is a “set state”, they don’t need to run on the server.
