Assigning null (empty) to a custom state failed to change the state’s value to null.
Debugger failed to show that the custom state was not properly set to null.
and one big question at the end.
(@seanhoots, you may be interested in this since it relates to a problem I thought I had with Air Date/Time Picker.)
I reported the first bug to Bubble as a bug. The Debugger bug is implied but not reported explicitly.
Here’s the situation.
The page has a custom state of type Date. It is named vDateDue.
In the workflow of an icon’s click event (could just as well be a button’s click event), vDateDue is set to null.
(note the breakpoint)
and the page’s Type of content (named Action) is updated:
DateDue = This Page’s vDateDue
The page has two date/time picker elements displaying the results of the workflow:
one has vDateDue as its data source (“Initial content”)
the other has Current Page Action’s DateDue as its data source
At the start, the thing’s DateDue and page’s vDateDue both contain a valid date.
After running the workflow, both items still contain their date values.
For good measure, immediately after setting vDateDue to null, the workflow writes the value of vDateDue to a log table. (This turns out to be the only hint of what’s really happening to vDateDue.)
Let’s look at the debugger at the breakpoint where vDateDue is set to null:
It says vDateDue has value = (empty).
Let’s look at what’s really in vDateDue, as evidenced by the log written in the next step of the workflow:
Both Date/Time Pickers show the same date even though they should be null.
The big question: What is Debugger doing?
Is it simply restating the instruction (code) even though it didn’t execute as instructed,
or is it showing a true result of the assignment of null to vDateDue but its value was mysteriously set back to its original date immediately afterward.
In either case, Bubble and its Debugger cannot be trusted to show what is actually happening during execution.
@laurence you’ve put a good amount of detail into this post : )
A more exact interpretation is:
This workflow step is about to set a custom state (vDateDue) to a value (empty).
When you run the workflow without the breakpoint, does it work correctly, i.e. does the Action DateDue get set to empty?
I think the buggy part here is the debugger pauses the workflow on the client side, but on the server side it sees the pause as being on a client-only action (custom state), so it charges ahead with the next step(s), which pick up the “current” values of the custom state to use to modify the database.
And last night I found that even with logging, the results are inconsistent between the variables seen (logged) during the workflow and what finally exists after Bubble comes to rest. I may post my observations in a day or so after I dig more deeply into it.
The debugger is great where you don’t have background workflows. And where the database updates are fairly small.
However, if you are kicking off API workflows or you have a lot of related things being updated, you can sometimes get different results depending on how fast or slow your workflows run.
So if you pause between two workflows, the data gets updated in the background, and you don’t get the contention that you can sometimes see.
I was kicking off 10 API workflows that all updated the same thing, and around half would fail with no error. The only way to see what was happening was to have a log between each step.
Makes me long for the good old days of Visual Basic and single-thread processing. But I am slowly getting to understand more of what’s happening under the covers of Bubble. And at least with Bubble, I’m able to build something that is cloud based and runs on my phone, tablet and computer.
