What Is Bubble Doing to Prevent Scheduled Workflow Failures During Downtime?

georgecollier · 2024-11-14T16:04:00.285Z

pachocastillosr:

because the manual indicates that, in the event of server downtime, this type of workflow will pause and then resume when resources are available again.

Yes, because you can’t ‘pause’ a recursive workflow…

The point is, if you have a recursive workflow, or any mission critical workflow, you should build error handling in. We take it for granted that Bubble (generally) works, but it’s normal in apps in any framework to have to be built to handle when things go wrong.

JohnMark:

What’s more, all my schedules are now logged

Things like this make your app more robust. When you schedule a workflow (or multiple), create a log for each one which contains the workflow ID. Pass that to the workflow itself, and mark the log as complete when the workflow is complete. If any logs are incomplete, you know something didn’t run.

pachocastillosr · 2024-11-14T16:05:40.393Z

georgecollier:

This is the kind of thing you can get an answer for from support

Sure we can just ask everything to support and not use the forum. I just think this would a valuable information for all the community to have. Also, an opportunity for the community to share their feedback about this for the Bubble team to keep improving the product.

Thanks for your input

pachocastillosr · 2024-11-14T16:07:22.095Z

This are some good insights, thank you for sharing

pachocastillosr · 2024-11-14T16:16:04.951Z

georgecollier:

Yes, because you can’t ‘pause’ a recursive workflow…

What I understand is: specifically the action of “scheduling the list of workflows”, has the capability to pause during a downtime and continue scheduling workflows later when server is back up.

However, if the workflows were already scheduled, they will behave just as if they were scheduled by a single “Schedule API workflow” and, according to my experience, not run at all if a downtime occurs during their scheduled date (this final part is what I’m looking for Bubble to clarify, it might depend on the type of incident, although we might all have our thoughts, I can’t find an official pronouncement about it).

pachocastillosr · 2024-11-14T17:47:09.363Z

Anyone, share any ideas on how you’d build an automated retry system for scheduled workflows that didn’t run because of a downtime.

Consider:

What if a downtime occurs when the retry system is supposed to execute?

Chatgpt’s suggestion:

To create an automated retry system for scheduled workflows that don’t run due to downtime in Bubble, consider a multi-layered approach that uses logging, periodic checks, and retry logic with a focus on resilience. Here’s a strategy that could address this effectively:

Logging Workflow Schedules and Completion Status

When you schedule a workflow (or workflows on a list), log each schedule in a separate “Workflow Log” table. This table should capture:

Workflow ID

Type of workflow

Scheduled time

Completion status (e.g., “Pending,” “Completed,” “Failed,” or “Retried”)

Last attempted execution time

In each workflow, include a step to update this log as “Completed” once it finishes successfully. This way, you have a record to identify workflows that didn’t run or complete.

Implementing a Monitoring Workflow

Set up a periodic check (e.g., every hour) that scans the “Workflow Log” table to find workflows with a status of “Pending” or “Failed” and a scheduled time in the past.

This monitoring workflow should retry any workflows that were missed, marking them as “Retried” once rescheduled.

Building the Retry Logic

Immediate Retry Upon Detection: When the monitoring workflow identifies a missed workflow, it can attempt to reschedule it. However, instead of just one retry, consider building a series of incremental retry attempts.

Retry Attempts: For each failed workflow, set a cap on retry attempts (e.g., 3 attempts with exponential backoff, such as retrying at intervals of 5 minutes, 15 minutes, and 1 hour).

Flagging for Manual Intervention: After the maximum retry attempts, flag the workflow as requiring manual intervention. This can trigger a notification to an admin or team member to review the issue.

Handling Downtime During the Monitoring Workflow

Since the monitoring workflow itself could be affected by downtime, consider using redundant checks. You could set up multiple periodic workflows at staggered intervals (e.g., one every hour and another every 6 hours) to catch any workflows that might be missed.

Persistent “Final Check” Workflow: At a less frequent interval (e.g., once every 24 hours), set up a “final check” workflow that reviews all logs with a “Pending” or “Failed” status. This final check can act as a failsafe, ensuring that no missed workflows linger indefinitely.

Using Conditional “Catch-Up” Logic

Add logic within each workflow itself to perform a quick check against the “Workflow Log” before running. If the workflow was already completed, it can exit early to prevent duplication. This is helpful in scenarios where multiple retries might accidentally trigger the same workflow.

Tracking Retry History for Insights

In the “Workflow Log,” maintain a retry count and a timestamp of each retry attempt. This will help you monitor any patterns in failures and investigate root causes.

Consider an External Ping for Extended Downtime

For critical workflows, consider setting up an external monitoring service (like a cron job or uptime monitoring service) to ping your Bubble app at regular intervals. If it detects downtime, it can automatically notify your team to check on critical workflows.

Example Workflow Execution Plan

Let’s consider an example where you schedule a workflow at a specific time:

Initial Schedule: Log the workflow in the “Workflow Log” table with a “Pending” status.
Execution Check: When the scheduled workflow begins, it first checks the “Workflow Log.” If the status is “Pending,” it runs and marks the status as “Completed.”
Monitoring Workflow: Every hour, this workflow scans for any workflows with a past scheduled time and a “Pending” status. If found, it increments the retry count, attempts to re-run the workflow, and updates the last attempted execution time.
Retry Limit and Manual Intervention: After 3 failed attempts, the monitoring workflow flags the record for manual intervention, notifying an admin or triggering a separate alert workflow.

Resilience for Large-Scale Operations

As your app scales, this retry mechanism can help ensure that workflows critical to billing, refunds, and data processing remain reliable. The scheduled retry system will catch and retry missed workflows automatically, and the log will make it easy to review any issues in your backend.

This approach should allow you to keep track of critical workflows, recover missed schedules, and handle downtime without having to manually monitor every workflow.

tylerboodman · 2024-11-14T18:38:48.466Z

Yea that could work

pachocastillosr · 2024-11-14T18:50:29.553Z

The absence of a database locking feature in Bubble creates a risk of the monitoring system triggering the same workflow twice if it checks the workflow status at the exact moment it’s already being executed but hasn’t yet been marked as “completed.” This overlap could result in duplicate executions, which may not be a major concern at a small scale but could become increasingly problematic as your app scales. Without a locking mechanism to ensure that only one process can modify or access the status at any given time, this monitoring system could introduce new, potentially more significant issues than the original problem of retrying missed workflows due to downtime, particularly when dealing with workflows critical to business operations.

ramzizi · 2024-11-14T20:36:12.357Z

I have the same concerns you do regarding critical backend workflows. It would be great if bubble was able to catch what scheduled tasks were missed during an outage and restart them.

pachocastillosr · 2024-11-14T20:45:11.013Z

Vote for this feature here

randomanon · 2024-11-14T22:54:31.569Z

Don’t overengineer this. For anything critical, on that same table, create a “Date checked” and “Date scheduled field.” Every so often, according to your WU cost tolerance, run a scheduled workflow on a list to find cases where there’s a discrepancy between the date checked and date scheduled field.

pachocastillosr · 2024-11-15T14:55:22.133Z

Thank you for replying. That monitoring scheduled workflow might also fail to execute during an outage, which would cause it to not run and not re schedule itself, breaking the recursion. But I understand your intention and I’m truly a fan of not over engineering, I wish there was a simple and reliable solution for this, that’s were I think Bubble could help.

randomanon · 2024-11-16T06:53:49.962Z

Not recurring, schedule workflow on a list, that’s concurrent.

pachocastillosr · 2024-11-16T08:29:50.706Z

Oh, so you meant to manually trigger the monitoring system periodically, yes that could work. However, I think it’s not a scalable long term solution. An automated system would be more appropriate.

building4stripe · 2024-11-19T22:33:38.835Z

Wanted to get some more detailed information from the support team directly, so I reached out to them asking them to provide more information about what happens to workflows scheduled during downtime. Here’s the response I received:

I completely understand your concern regarding scheduled workflows, especially in light of the recent downtime. I want to clarify that Bubble does attempt to re-run any scheduled workflows that occur during brief database or main cluster outages. When there is a short downtime, for example, the database goes offline for a few seconds, our procedure retries any queries that were affected during the crash. However, in rare instances, a very small number of these queries might not be retried successfully.

That being said, if the database or main cluster experiences an extended outage (for longer than a few seconds) the workflow will likely fail. In such cases, please don’t hesitate to reach out to our team. We’ll do our best to provide more details on which workflows were affected and help troubleshoot further.

Our engineering team is actively working to improve this process, and we are keeping a running list of all occurrences to maintain transparency with our users.

That said, I want to emphasize that this situation is extremely rare, and our retry procedure for queries after brief outages is generally very reliable. If you experience any issues following a more major outage, please don’t hesitate to reach out to us.

Conclusion: For important workflows, the type of failsafes you’ve discussed are crucial. We’ll definitely get going on that for our apps.

pachocastillosr · 2024-11-20T03:42:34.102Z

Thanks for sharing. While the recent outage was brief (as they said), I did experience scheduled workflows failing to execute entirely. This highlights a critical issue: Bubble still lacks a truly reliable infrastructure solution for this, and didn’t provided you with a clear roadmap on how they are addressing it.

These are the kinds of improvements that would help Bubble evolve into a more robust platform capable of supporting enterprise-grade applications at scale. Reliable infrastructure is essential for users building and scaling such apps.

bonjour_17 · 2024-11-20T05:33:36.691Z

In addition I’d say that bubble lack as well a way to access the scheduled workflow list programmaticaly. For example if you need to schedule 1 workflow maximum per user and need to check if one already exist before scheduling another.

Also, a “schedule workflow on a list” does not have the same usecases than a recursive workflow - as things are not run in sequence. Giving out advices to use one instead of another is not a solution in many cases.

randomanon · 2024-11-20T10:55:20.205Z

@georgecollier had a hacky way of using SWOL recursively IIRC

ZubairLK · 2024-11-20T12:52:59.819Z

I don’t think this is a bubble problem.

Lets imagine I had a server in AWS running the scheduled workflows every hour.

& for whatever reason. Maybe some memory leak. That critical server running those operations crashed for 6 hours.

Now what would I do?

I would attempt some manual process to start the ones pending since the last 6 hours.

Run a script manually on the server or execute a command manually.

Or I would build some error handling to continue the hourly executions where they are left of in some type of queue rather than time based.

You essentially need to store information about whatever process was run vs not run in the database & only trust the database.

I think the dates flag above was mentioned.

This is a software engineering problem. Not a bubble problem I think

Thanks
Zubair

azkytech.com

AZKY Tech Labs: Launch your new product in weeks!

We use NoCode to build products faster and help you get to product market fit quicker!

gf_wolfer · 2024-11-20T15:16:01.623Z

ZubairLK:

I don’t think this is a bubble problem.

I tend to disagree. Since Bubble is a contained system, when they have outages we do not fully know about the scope of the outage and what exactly is affected. If it was my own server, I have ways to know the exact seconds when it was down and can accurately proceed from there.

Even if I check the forum every hour, have notifications to the Status page, I cannot know about every outage that Bubble experiences and what specifically is affected.

( I have a specific back and forth with Bubble support about an ‘extremely rare’ server downtime that occurred in the middle of a running workflow, so it corrupted the Data. We only found out through user bug reports on the corrupted data and really have no way to lookup if this has happened before…)

And I think that comparing Bubble to building our own infrastructure seems unfair since it is meant to one, make technology accessible to everyone, and two, people have beat the drum enough on the big cost difference between the two to know that we are paying for something different than a simple server, so I do not see this as an apples to apples comparison.

As an originally non-technical person, this sounds exactly like what I would expect the Bubble system to do

ZubairLK:

I would attempt some manual process to start the ones pending since the last 6 hours.

Run a script manually on the server or execute a command manually.

Or I would build some error handling to continue the hourly executions where they are left of in some type of queue rather than time based.

You essentially need to store information about whatever process was run vs not run in the database & only trust the database.

pachocastillosr · 2024-11-21T15:52:37.859Z

Hi everyone,

With the help of ChatGPT, I’ve designed a more complete description for the feature request, you may vote for it here (its the same link I shared before).

Proposed Feature: Customizable Workflow Behavior Settings

The idea is to allow users to configure what should happen to their scheduled workflows in the event of an outage. When setting up a workflow, users could define their preference from the following options:

Retry Automatically: The workflow is retried automatically once the system recovers from downtime.

Example Use Case: Generating end-of-day reports or processing batch jobs that remain useful even if delayed.

Cancel if Missed: If the workflow misses its scheduled time due to an outage, it is canceled and not executed later.

Example Use Case: Sending time-sensitive notifications, such as webinar reminders, where delayed execution would cause confusion.

Prompt for Review: After the outage, workflows flagged as “missed” are paused and require manual intervention to execute, skip, or reschedule.

Example Use Case: Complex processes like billing adjustments or refunds, where the timing and accuracy are critical, and manual review might be safer.

Additional Features for Reliability

Logging & Notifications:
All affected workflows could be logged in a dashboard, with notifications alerting users of their status (retried, skipped, or awaiting review).
Outage-Resilient Queue:
Workflows affected by downtime would be temporarily stored in a queue, ensuring none are permanently lost. The queue could respect user-defined behavior (retry/cancel/review).
Retention Rules:
For workflows marked for retry, users could define a retry window (e.g., “Retry within 24 hours, then discard if unresolved”).

Share your thoughts!

Thank you