Sharing my experience in hopes of sparing another Newbie the anguish.
Some background:
Tail end of first app underpinning a soon-to-open physical location. While testing our API WFs, i entered test cases with shortened reschedule API times (+hours:1 instead of +days:7). i’d read about how recursive API WFs looping through lists without sufficient end-conditions would run up massive WU, but since we don’t process any lists in backend WFs i wasn’t worried. What i didn’t know: the hazards of scheduled dates in the past because Bubble’s internal logic wasn’t described anywhere (i requested an update to the Manual and they’ve added the sentence: Note that if you schedule an API workflow in the past, it will trigger immediately.).
To make a week-long story short: Since WFs scheduled to run in the past are immediately triggered and dates are treated as date 12:00am, if an API WF is rescheduled in the backend with date +hours:1, then after 01:00 the WF will have a scheduled date in the past and will continuously reschedule itself (NOT every hour). The one field which i thought would update every hour ended up using 1 million WU in a couple hours…
So i applied for a WU waiver and now our site has been down for a week (honestly didn’t think the WU waiver review process would take this long); and our opening is postponed indefinitely because Bubble has been unable to tell me how long the ‘process’ will take (although i’ve just been informed that the request has --finally-- reached the ‘highest level of required approval’ so maybe sometime next week our site will be back up - i’ve worked in orgs of 30k-50k which felt leaner than this, sigh)…
Lessons Learned:
- When rescheduling API WFs in the backend make sure none of the scheduled dates can Ever Ever Ever Be In The Past. Especially when testing using shortened times (<1day) and date (use Current date/time instead) !!!
- If you’re not sure, ask. Surprisingly helpful experts on the forum, although some are more snarky than others : )
- If you do make a mistake and run up a WU tab, you can write Support to request a one-time exceptional WU waiver. Maybe get used to the phrase ‘Workload requests must be handled and approved by many individuals across multiple levels of the company…Thank you for your patience.’
- If you decide to buy extra WU (Workload Tier), pause/cancel your WU-intensive Scheduled WF, otherwise …
- Am a bit torn on this last one. Am generally quite optimistic and used to think Bubble was The Best Thing Ever… but this past week of being stonewalled by The Big Bubble
B-u-r-e-a-u-c-r-a-c-y and being repeatedly told how ‘extremely important’ my app is but that there are many individuals at multiple levels involved in a ‘thorough approval’ of my request…
the doublespeak…has just changed something fundamental for me, like when you sense for the very first time that a relationship r-e-a-l-l-y isn’t healthy and you somehow know down deep that it’s not–it can’t be–a long-term thing…
Anyway, it’s all Live & Learn
Good luck on your journey, wherever it may lead
PS Submitted to Tier 2 Support (i was told to enter a suggestion on the Ideaboard, which I did…)
Let me try again:
- Bubble has intransparent internal logic which immediately triggers WFs scheduled to run in the past (where is this logic described?)
- Bubble also has logic that treats dates as date 12:00am
So if someone schedules a single API WF to run on a single date with a single task of updating a single field and then reschedule itself for date +hours:1 (instead of Current date/time +hours:1), then at 01:01 your scheduler immediately spins into a never-ending Twilight Zone loop of rescheduling itself, with no indication in the Scheduler that lots of workflows are running because it’s just one workflow running up a million WU in a couple of hours
My suggestion:
Either put guardrails around this or at the very least DESCRIBE IT CLEARLY IN THE MANUAL WITH WARNINGS ABOUT THE POTENTIAL COST OF MAKING THIS VERY SIMPLE MISTAKE!!!
i understand that more WU means more Bubble revenue but it would be the decent thing to do to be transparent to help the little guys avoid paying thousands of dollars for a simple little mistake
But maybe asking companies to do the decent thing is a stretch these days