I have a workflow which subtracts a number. If the remaining number is less than the amount to subtract I trigger an Alert. In the attached example, if I subtract any number greater than 5, I get an alert when I am not supposed to. I spent hours understanding why that’s the case. Can someone help?
- click on reset to reset the number to 10
- type 6 in input box
- click on subtract
you should see the number being subtracted but an Alert message saying othwerise.
Thanks for checking Shawn but I have replaced the dropdown with an input of type integer. Problem is still there!
Scratch that, your “CurrentRecord” state is being saved in the wrong State. I believe you have 2 states one for the button and one for the icon. Your saving the “CurrentRecord” in the icon state but comparing it with the Button State
I am away from a computer and using my phone so I can’t use the editor properly but check your States for the button and the icon
I have only one state. They are both the same, just renamed the Button appropriately. (I don’t have an icon, the name of the button was misleading)
I see it working fine now. Alert tells me when it can and when it can not decrement
If you click on reset and then subtract, you will still get the wrong alert . It only works for numbers smaller than 6!!
Try adding a pause right after the set state action and right before the alert action. It’s under Navigation > Add pause before next action. Leave the time to default 1000
See if that makes a difference, if not when I get to a computer I’ll take a look at your editor.
Added pause. Problem still there. Thanks for your time Shawn. I’m going offline now (3:40AM in my timezone ), will check back tomorrow!
Remove the pause and remove the Initial Value of 6 from your input field
Done, still same problem!
Did you use the debugger? The workflow is working exactly as you programmed it. Use “step by step” and click on every blue link that appears in the debugger, first the link in the left pane, then each element of the link that appears in the right pane. You will quickly find the logic error.
The debugger is essential for finding unintended results. If you need help using it, just reply.
I did use the debugger, but it’s showing me strange results. When I click on subtract button, it shows the number subtracted before even reaching the workflow which subtracts it. (might have just added an unrelated logic error when you were checking it). I spent too much time on this. If you could see the problem please let me know.
Its always safe to assume that all workflows occur simultaneously rather than sequentially as you see them on your screen. I don’t know whether terminate this workflow evaluates in the order shown in the workflow actions.
With that in mind, if there is a particular workflow step that you want to constrain or prevent, try putting conditions directly on that workflow step rather than trying to terminate the workflow prior to that step.
It seems that “make changes to the thing” occurs first, then that causes your evaluation for the banner to be different than what you think it should be. (and the dubugger does not really force a particular order even though it appears to)
I’ve never used it but perhaps “add a breakpoint in debug mode” on all the actions it may help get to the bottom of the evaluation order, or sometimes adding pauses between every single action can force a particular order.
I tried replacing the terminate workflow with a conditional custom event (see below). The problem is still there!
What’s strange is that I even have a version which behaves differently when using the debugger. Try running the following, with and without the debugger!!!
I’m not good at following other people’s terminology, but try this general advice:
Go back to your original model from your original post because that was your original thinking.
Add as many text elements to the screen as you need to track every value you are using, ie, especially “Button Subtract’s (state’s) Current Record’s Decrement” so you can see if that state is reflecting what you think it is when you press the “reset” button.
When I run into items that are difficult to trace, I put every value on the screen so I can see it real-time rather than relying on the debugger exclusively.
I would also clear out all the existing records and work with only one–since your searches have no constraints, it is unclear which Decrement you intend to be working with. Is it the last one that was created? In that case, your searches should also include sort by “created date” descending “no”:first item. That will ensure you are working with the most recent record.
correction: descending “yes” will make the most recent one the first item, descending “no” will make the oldest one first.
I looked only at your first example, and I agree that the behavior is, at best, perplexing. See the debug screenshot below, which clearly shows in step-by-step mode that the value has been decremented well before the step in the workflow which actually decrements the value.
I would suggest submitting a bug report for the @Bubble team to review. It’s likely related to Bubble’s attempts to maintain WF and “thing” consistency.
That said, I’m sure there’s a way to accomplish what was intended. I don’t have time to experiment right now, but maybe avoid the multiple Search for situation. As it is, the Remaining number text field performs a search as does the WF.
Thanks @sudsy, just updated the first example with your suggestion. Problem still there! I will file a bug report.
Thanks for your help and valuable suggestions @meyerhd2, when I first reported the problem I only had one record, I added the remaining records for different versions of the page. In any case I updated the example with sorting the search and printing the state to the screen per your suggestion. The alert is still printing the unexpected value. Furthermore the state is being subtracted before the alert . It’s subtracted as soon I press on the button before stepping through any workflow actions. I submitted a bug report as @sudsy suggested since he was also able to see the strange behavior in the debugger. I suspect you are right about workflows actions running in random order, but if you can’t guarantee a chronological flow how could you implement an action depending on another? Also what would be the use of Terminate flow if all actions in that flow run simultaneously!!