This problem has been reported at least three times before.
Topics have been closed but I don’t see that a solution was presented and I have been struggling with this for months. In total, I have probably burned more than a day’s time searching for errors in my workflow logic. Today, I finally took the last bits of workflow apart to discover the problem, only to discover that the problem has been reported but not resolved.
Since it has had a bug report submitted at least once, I won’t be doing that.
Hey, Bubble team, is there any hope of getting this fixed?
For now, I just need to work around this, i.e. not use terminate with condition.
If I find time to assemble an example to share, I’ll do that. If the problem is the result of a network (cascade?) of conditions in my app, it’s unlikely that I’ll figure out how to demonstrate this in a bug report.
Thanks, Jon. At this point, I’m way behind on the real work of making the app do what I’ve advertised that it will. This bug was an absolute stinker, and because it was so obscure, I don’t know how many places I gummed up the logic in feeble attempts to speed things up . . . yada yada yada
Next up, I need to test a feature on about eight pages that I disabled until Bubble techs presented a solution to another bug. Now it’s time to try reinstating that feature after ensuring that the Bubble fix did its job.
I came across another one today. The condition was simply this:
Only when inputName’s value is empty
inputName is an input element.
This element and workflow happen to be in a reusable popup element.
My workaround is to split the workflow in two, with opposite conditions on each. The extra work associated with the condition that terminated the original workflow is now handled in a separate workflow and doesn’t need to terminate conditionally.