It was meant to happen to someone I guess.
I suddenly logged in today and had 3M WU in the last 2 days alone (my projections are around 200k per month)
Somehow a workflow that has been running without an issue for a year or so, bugged and it gets rescheduled constantly. I managed somehow by clicking many times cancel to cancel it but I don’t understand why and how it kept on scheduling itself constantly. I contacted support but last time I sent about WUs and optimization it took me a week to get a reply so I’m quite f…d.
Are you sure that an old WF that you or another dev hasn’t change for a year went to infinity rescheduling?
May be you’ve changed some variable (some index used for looping, for example) that is used in that WF?
I am the sole dev and there is no reason for me to touch it because it is working fine Last couple of weeks I have not touched BE workflows actually.
I am trying to figure out what went wrong but logs are not helping at all. It’s like the workflow got scheduled with empty or undefined parameters (although they are mandatory)
As you can see the workflow has as a mandatory field the position parameter
Here it is clearly empty and yet the workflow run with an empty mandatory position.
The workflow reschedules itself if a condition is met but because it was empty, the condition was met (the condition and it kept on rescheduling itself).
I thought we have mandatory fields to stop WF from running if something it’s empty If not I’ll have to do A LOT of filters on the WFs I have.
Mandatory parameters in workflows serve different purpose. They highlight syntactical error mostly.
So if you have a place which is invoking that API workflow that has a mandatory parameter, it will just make sure that in the editor you are passing some parameter.
In run time that parameter could happen to be empty. API won’t mandate that to be non-empty. If you would want that to be non empty, you would have to put explicit condition yourself to check if it is non empty.
I want to believe this is not true. Otherwise bubble would not complain every time I try to schedule a workflow with a parameter that is empty but mandatory. If it is, it needs to be mentioned in the documentation. Not how really APIs work to be honest. the parameter expects a certain data type. In this case a position. If it does not receive that data type, then it’s simply not valid. Same way when you try to pass a number instead of a string you get an error that the parameter accepts only a string.
I was just telling how Bubble works. Don’t know what is the right thing here.
There are two things
“This parameter is mandatory to be passed by the workflow in Bubble which is calling it”
“This parameter cannot be empty”
I suppose even in APIs which make some items mandatory would accept scenario of an empty string being passed as parameter and would have to do some handling of it.
If you’d like the API to not work itself if the parameter is empty, then in the API at high level itself you can put the condition of parameter not being empty.
@mghatiya is right, by you leaving the “Optional” box unchecked the only thing this does is require you to pass in a parameter (whether a static value or a value from a variable), and does not check whether the value passed in is empty (in the case of variables or string literals).
This serves more as type-safety, allowing you to make the assumption that the value will always be passed to the workflow; if you need to make the assumption that the value is never empty from within the context of the workflow, you need to add a “Terminate this workflow” as Step 1, terminating if the value is empty.
Last couple of weeks I have not touched BE workflows actually.
If not I’ll have to do A LOT of filters on the WFs I have.