Sorry but this seems a little odd since the only way of not having race conditions is to use recursion.
To me this sounds really threatening. If you tackle the race conditions problems and solve them once and for all it might be okay with not having recursion anymore.
But anything else than this will harm many projects tremendously…
I want to clarify what I meant here by “moving a away from recursive workflows.”
Our intent over the medium to long term is to build native solutions that are better suited for the kinds of tasks being done by recursive workflows today. If we build these correctly we should see users like yourself begin to migrate their new and existing use cases to these native solutions organically.
We have absolutely no plans to disable or otherwise prevent users from leveraging recursion as a method in Bubble.
@boston85719 there’s a lot to unpack here in your response, but here are a few thoughts:
First and foremost, I’d like to reiterate the intent of this feature is to provide a backstop across apps that can significantly mitigate the impact of unintentional, runaway recursive workflows. What this feature is NOT, is a tool to help you dynamically manage and control recursive workflows in your app.
The potential issues you raise around problems or risks with constraints on scheduling recursively are very real. This feature is not intended to address those. I’d also posit that those risks are inherent with recursion, as you point out that there are countless ways to make mistakes. It’s my opinion that the best way for Bubble to help here is to provide native solutions that don’t involve recursion at all.
I would like to quickly clarify that the situation you refer to below is in fact captured and mitigated with this feature (“indirect recursion” - see this section of our docs.)
FInally, I’d like to thank you again for your thoughtful response here. Your familiarity with building on Bubble and passion around how we evolve the product comes through clearly. I can assure you we do speak with our more advanced users, and I will be reaching out to you directly to better understand your challenges and help us refine our roadmap.
That has always been understood. If there is confusion on my understanding of this, it may be because I as you agree the best way forward is to add features and functions to eliminate the need for the recursive backend workflow workaround, and in a previous reply I reiterated points other users have made as features/functions that would be helpful in that endeavor to be added to the schedule backend workflows on a list function.
I just personally believe the feature would have been better at mitigating impacts of unintentional, runaway recursive workflows if it was placed on the workflow level rather than app level.
Agreed. Is there any timeframe for those to be released or a roadmap of sorts that would list the types of features that will be released to reach that point?
Awesome! Probably the best use-case for the app level setting.
I’m always willing to lend my advice and enjoy getting some direct communication with the various team members at Bubble. Keep up the good work, as I appreciate your time and responses here.
Love this! Huge update. Just had a client spend 300k WU in a couple of minutes due to a bad recursive workflow.
I am with all the points raised by @boston85719 here.
I wonder which serious apps would really use this app level setting and limit all their workflows from being run at a certain depth. And out of those I wonder how many won’t put this limit to be really high number like 50K etc (and thereby almost defeating the purpose of feature).
I won’t be using this setting surely. As highlighted already by others, there are many cases for needing high depth of workflows, and putting an app level limit would restrict those.
This limit/setting should have been either at workflow level or we should have first seen work on making schedule workflow on list have better controls like having an index or assuring serialisation, assuring data integrity, handling race conditions etc.
This.
Thanks for your response. georgecollier & adamhholmes are just like boston among the most experienced and helpful people on the forum. They have Bubbles best interest at heart, do you mind to also reach out to them about the roadmap?
I’ve just spent the last 4 hours trying to debug a workflow and found myself here
I have a backend workflow triggered on a list that works in Test but fails in live. Both instance’s are the same code wise. The process worked on the 21’st of last month but failed from the 28th.
Checking the settings, the default was None for both but even setting this to 5k doesn’t seem to work. Does this take some time to take effect?
Also adding I see no errors in Bubble logs or Flusk logs. THe logging just stops when the workflow is triggered, almost as if the scheduling has been paused (it hasn’t.
Im also set for 1,000,000 WU’s and this is day 2 of the month so hardly any WU’s have been consumed yet.
