@anders.eidergard does it happen to have a conditional (ie “Only When…”) tied to the action?
Yes, it does.
It’s checking a custom state value on the page.
I tried making it all into a single workflow instead of in a custom event and that worked.
The flow is the exact same with the only difference being that it now runs in a single workflow instead of part of it being in a custom event.
A bit more work since I can’t reuse that custom event and have to make changes in several places so that’s a bummer, but at least it now works for my users.
This is great! Thanks so much.
Hey @anon38627393, thanks for the reply and sorry for the late response on my end. I agree that we definitely could have done better in the way we rolled this out. Going forward, we’re planning on rolling out these workflow changes as a Bubble version, which should prevent all of the issues you mentioned in your reply happening. With a Bubble version, app owners are in control of when an update is rolled out so there’s no unexpected outages and (hopefully) no need for update alerts 24-hours prior to a major deployment. That said, if you have any suggestions about how this process could be better, we would love to hear them. We really appreciate your input and help with this whole process, and thanks for bearing with us as we improve our operational procedures.
3 Likes
Hey @gf_wolfer, I just responded to @anon38627393 but I want to agree with you and let you know that we’re definitely aware of this situation on the engineering side. We don’t want to have to bother users with every update we push, as we update pretty frequently, so we only release a change as a Bubble Version if we know that it’s going to break user’s apps. Here, we thought it wouldn’t break anything, but we didn’t realize that workflows that are structured in a certain way are in fact broken by these changes.
(If anyone’s curious, here’s what broke: workflows that have these two actions in the same set of consecutive database updates: 1. update the database 2. another database update that relies on an “Only if” conditional, which is constructed with a “Search for … : count” dynamic expression". This issue was resolved last week, so if you notice workflows of this kind, or any kind, not working, please submit a bug report!)
Going forward, we’re going to use the Bubble Version system for updates like these so that apps don’t unexpectedly break. We hope this will prevent issues like this from happening in the future.
3 Likes
Hi @ryanck, the workflow performance improvements are not currently in effect because we disabled them temporarily in order to fix a bug some users were having. The improvements will be deployed next week, so that if anything goes wrong we can quickly respond (most of the engineering team is off the the holidays right now).
1 Like
Hi @anders.eidergard, sorry that your app isn’t working, although I’m glad you were able to find a workaround. If you haven’t already, would you mind submitting a bug report? This will help us fix the bug.
Thank you much @henryd. The notion of a version increment solves this issue nicely. Appreciate your engagement here with the user base, very much. How about this thought: are the Bubble updates pushed out as specific times of the day? I recognize it’s probably both impossible to A) know if an update could potentially or not potentially break existing app structures and hence concretely know whether or not it should be a dedicated version increment, and B) to actually make every single update a version option. Hence, because we’re dealing with this rock and a hard place, perhaps if the high-frequency updates were put on scheduled release cadence, we could still anticipate potentials. AKA I know updates are pushed around 11AM EST every day, so I know prod ops needs to check health and logs at 11:10 every day.
Working for a particular large, and technically-disparate, large bank comes to mind here, where they managed hundreds of possibly-high-impacting prod updates per week. In events where testing the impacts of each one was impossible, the hard-rule was there was a set time and frequency for prod pushes (which was once and only once per week), so that all affiliates/departments/tech teams knew when to be on call and to watch for sudden defects and failures. The flip side of this is, if a dev missed the cutoff for his particular change, he had to wait for the next prod push round. No exceptions.
That sort of model could work here. Food for thought.
Appreciate you much.
EDIT: P.S. SEV1’s were always an exception. And the real cadence looked like all updates: once per week, always followed by a minor push 36 hours later of all the fixes that the weekly push broke haha. Emergency SEV2 fixes only, no additional dev, for that mini-push.
Maybe we can implement a simple Request For Comments system? During development/design, there can be a post made to the form that can solicit comments about how these changes may affect our apps. I understand if it can’t be made out on a public forum, but maybe even in a private one.
1 Like
Hi @ryanck, we’re re-rolling out batching at the beginning of next week. When we do, we’ll roll it out as a bubble version, so you’ll have a chance to test the changes in development before rolling out to production to prevent further hitches.
6 Likes
FYI: just rolled this out. Took a bit longer than we had hoped because of some issues with testing, but we’re confident that the version we deployed today is stable. To enable batching, upgrade to Bubble version 11.
7 Likes
Hey @anon38627393, thanks so much for this message and my bad for not responding to it sooner. I really appreciate the suggestions you made, and we’ve actually discussed some of them in internal meetings about improving Bubble’s reliability. While I can’t make any promises about what will actually be implemented in the future, we’re definitely working towards making the experience of maintaining a Bubble app easier and less stressful.
@david17 Thanks so much for the comment, and sorry for not responding sooner. This is a really good idea, and it’s quite likely that we’ll try using some version of user feedback for features in development in the future, be it through a focus group, request for comments system, or something else.
this is epic! Well done, looking forward to seeing the improvement in performance.
Great stuff.
1 Like
!
Hi, How does this affect backend workflows that need to be looped? That depends on the results from one set? example below
send a list of items with values 100, 200, 300, 400, 500 and an operation amount of 400.
Backend workflow is as follows
create item 1 in a new table with value 100
make changes to a different record using step 1’s value
update operation amount 400 - 100
Then loop through all the items until operation amount is 0
Right now its completely broken. How would we structure these types of workflows?
Hi @adunniola, sorry your workflow isn’t working. This update should be completely behind-the-scenes, so it shouldn’t break any workflows that previously worked. If it’s still not working, can you submit a bug report so we can investigate this behavior further?
Hi Henry,
I literarily just fixed this for my workflow. But i will still go ahead a submit a bug report. I think what has happened is that while the performance improvements are really fantastic, it affects previous recursive workflows that used a DB update as a condition for starting the “loop”.
If i understand correctly, with the new improvements, for recursive workflows running on a list, the “create”, “Make Changes to a thing” actions are done simultaneously and it updates the DB . This also then means that the “operational Value” is already updated and will be used for the next “thing” on the list.
It however requires thinking more simply about the results and structuring the “loop” in a different way.
Thanks so much for your response.