Has anybody else began to experience issues with applications not on a custom domain that when testing in debug_mode everything works fine but when not in debug_mode things start to break down?
I’m experiencing it, but it might be isolated to a particular plugin.
Just curious if anybody else is having issues.
FWIW, I rarely use debug mode, and I’ve not been experiencing any issues.
-Steve
@boston85719 I am currently experiencing an issue with a workflow - works when in debug mode but not when not. Very frustrating!
I’m basically having to redo multiple workflows, seems like almost an entire feature set of the application. Extremely frustrated. Never thought that I’d have a complete application working flawlessly in with debug parameter in URL while in ‘run’ mode but when removing the debug parameter everything falls apart.
Very frustrating!
Same workflow is working in prod, but has just stopped working one day in dev - and it’s only a 2 step workflow.
Just found another 2 step workflow that only works on the step by step debugger (not working in prod either…oops)
I’ve only seen this issue when I was stepping through the workflows one at a time vs running continuously.
Have you discovered what was the issue with the original build that caused problems when you removed debug mode?
What Bubble support told me was similar to the developer of the plugin that causes a lot of my issues; it is about timing.
Overall, they both touched on one key point about custom workflow events. If a custom workflow is triggered in a series of actions, that custom workflow will run and complete before the next step in the series is triggered. So step 2 is a custom workflow with like 15 steps, they all will be completed before moving onto step 3 in the original series.
For me the use of custom workflows came in handy and helped in one situation.
Other times, timing was still the issue but custom workflows were not possible. Using a ‘pause’ workflow event got 1 of my issues resolved.
I still think it is a bit of a flaw in how Bubble processes workflow actions when debug_mode is in the URL parameter. For me, using the debug_mode=true in Run mode should replicate exactly what a production app would be like, but it doesn’t.
Whenever I have issues and I run in step by step and they work, it is usually indicative of a timing issue.
I have fixed a few of the issues and I’m hoping not to discover any others because the feature set is very complex and incorporates a lot of reusable elements, repeating groups, plugins and processing of dates.
What the issues are related to is timing. I’ve so far employed several different techniques to resolve.
One for example was associated with a reusable element that uses the URL for filtering data from the database to be used in constructing date ranges and then sending them to the page to populate a repeating group representing a week.
My first finding was that when the page was loaded everything worked as expected, but when the dropdown used to change data that triggers all the steps had a final step of navigating go to page which changed the URL parameter used in the reusable element things did not. When in debug_mode it does, even when in Run mode; which was strange to me when I built it to begin with.
When debug_mode was off and things didn’t work, I first put the go to page navigation as the first step to change the URL parameter and everything worked fine. Of course this is not allowed, despite working, it causes an issue in the issue checker as go to page can’t be any step except the final step.
So for this I put a custom state equal to the parameter. Then when the dropdown is changed I put a single step workflow of go to page to change the parameter. I then added a conditional workflow action to run every time the URL parameter did not equal the custom state.
That conditional workflow action triggered all the steps I originally had running before the go to page. So I effectively tricked the system into allowing me to use go to page as a ‘first step’ so I could change the URL parameter and leave all my workflows in the reusable element untouched.
@Zaque and @equibodyapp
Something from my debugging without the debugger today has found an error that seems to be related to others I experienced before, and again it seems to be a timing issue.
I believe Bubble support attempted to provide this insight without specifically naming the issue, which is related to Conditional Workflows.
I have already changed the use of conditional workflows in other areas, and have found yet another that needs to be changed as the condition getting met has a timing issue.
The date count that this Conditional workflow is triggered off of is 3 for example. Other workflows continue to run until this conditional workflow is triggered, however it runs 5 times instead of only 3 and this conditional workflow doesn’t get triggered until after the 5th run of another workflow which causes an error.
I’m so sorry you have to rework all these features, @boston85719 such a huge bummer, but really appreciate your sharing the details here so we can all benefit from the lesson and try to avoid the issue in our apps!
By chance has bubble support agreed that “using the debug_mode=true in Run mode should replicate exactly what a production app would be like”? (e.g. confirmed this a bug?)
I received these comments separately
Using the debugger in normal mode should not impact the speed of the workflow but may change the order of simultaneous workflows like ‘page is loaded’.
We do understand that the debugger sometimes changing the workflow behavior is frustrating and it is on our radar to improve this
As well as this initially
it seems to be related to how workflows are being processed in Bubble
And some tips in the beginning
However, here is some information about workflow logic in Bubble. First a few general rules about how workflows are run:
For optimization purposes Bubble runs workflows asynchronously on the server and client side.
Frontend workflow actions run in order but the next action does not wait on the previous action to be over before being triggered.
Backend workflows are triggered as soon as the workflow is triggered, independently of steps. For example, a ‘Schedule API Workflow’ action will be triggered as soon as the workflow is triggered even if it is placed last in the workflow.
Custom events run in sequence, not parallel. If a workflow 1 triggers a custom event that starts workflow 2, workflow 2 should complete before anything in workflow 1 runs.
Searches aren’t always immediately updated with new data. So if you create a new item, and then try to retrieve it via a search, it may or may not work; you should not rely on this.
Retrieving a thing from “result of step X” where step X is the “Create…” step should always be safe.
Workarounds to help you solve your workflow consistency issue:
- When a workflow trigger (eg. a button) can have multiple results based on conditions, it is safer to create multiple workflows and place the conditions at the workflow level instead of creating one workflow with all possible actions and placing the conditions at the action level.
- In a workflow with two actions, if action B is using a condition based on a search depending on data manipulated in action A, then action A should be implemented into a custom event to make sure it is finished before moving on to action B.
- If a backend workflow should be triggered after other steps in the workflow, then it should be implemented into a custom event placed after the steps that need to come first.
- The safest way to use data from one step to another is to use the “result of step X” operators instead of searches.
- We do not offer an action to wait for a workflow to be over before moving on to the next step; however, using a ‘add a pause before next action’ action is usually an effective workaround.
This topic was automatically closed after 14 days. New replies are no longer allowed.
