Debugger: Data (Things) actions ignores "step-by-step" mode?

[artemzheg]

Haven’t paid attention before, but while making some debugging stuff today I was a little bit confused.
Within a single workflow I have a mix of actions that can be divided in 2 types:

1. No interaction with a database: setting custom states, resetting inputs and so on.
2. Interaction with a database: creating and modifying different Things (using Data (Things) actions).

So what I’m expecting is that “step-by-step” mode of the debugger will allow me to execute ALL actions step-by-step. Actions of type #1 are respecting my expectations and run only when I ask them to perform (with the “run next” button). But actions of type #2 don’t care at all - they ALL perform as soon as workflow triggers. So everything is created/modified in database and what I’m seeing in the debugger is just “look what we’ve already done”, not “look what we are going to do”.

I’m aware of Bubble action execution rules:

• Frontend workflow actions run in order but the next action does not wait on the previous action to be complete before triggering.
• Backend workflows are triggered as soon as the workflow is triggered, independently from steps.

But somehow I thought that debugger “step-by-step” mode has some power to execute ALL (even backend) types of action only with “run next” button click. While searching through the forum I’ve found this reply from Bubble team member:

Hello! The thing to keep in mind here is that all steps within a workflow complete roughly at the same time once the workflow is initiated. With the debugger in step-by-step mode, the workflow still completes at the beginning, so the values in the evaluator are viewed after the workflow has completed.
[source]

Could some Bubble OGs confirm this or am I missing something?

[keith]

Yeah so database operations will only wait for preceding actions if they depend on the result of some preceding step. See the link to the post by ashofer linked in the forum post. And see the video therein if you like listening to me prattle on about this sort of stuff:

FLOPPY: Plugin for localStorage, sessionStorage, IndexedDB storage, List Creation/Manipulation, Iteration, and More! Now with even more video docs!

Oh hai - here’s a new freestyle video where I talk about synchronous vs asynchronous actions (in general) and then demonstrate the new Sync Trigger feature in Floppy. I kind of departed from my intended script here, so I’ll probably do a followup, but this should be helpful to someone… Oh, and here’s the very helpful post I mentioned in the video, wherein Tip: Order of Operation - #2 by aschofer @ashofer from Bubble gave some helpful insights into synchronicity/asynchronicity of Bu…

[keith]

As far as step mode in the debugger I’m AFK at the moment but it wouldn’t surprise me either way if it database steps executed in the same way as normal or not. (That is, when stepping thru steps in a workflow, the debugger is highlighting the action step in question but effect of that step may in fact already have triggered).

[artemzheg]

@keith

As far as step mode in the debugger I’m AFK at the moment but it wouldn’t surprise me either way if it database steps executed in the same way as normal or not. (That is, when stepping thru steps in a workflow, the debugger is highlighting the action step in question but effect of that step may in fact already have triggered).

I’ve just reproduced the same test scenario from the video you’ve shared above: 3 customs states (running synchronicity, one after another) and “create a thing” action in the end (taking custom state #3 as a value for a field).

Test results:

1. Custom states are determined and new thing is created as soon as I trigger the workflow in “step-by-step” mode. So debugger mode has no influence on database related actions.
2. But custom sates are not shown in text fields I’ve created to display their values (just a text element with dynamic expression custom_state_x’value) I until I manually get to the corresponding step in the debugger.

So now I’m curious if “set state” actions are performed like server side actions → right after triggering the WF. Is there a possibility to check custom states values at the browser level or via chrome dev tool (I’ve tried, but the only matching text value was returned for created thing, not a custom state)?