[Feature Update] Changes to the way copying and restoring the scheduler works

Hi all,

We’ve deployed some changes to the way some Bubble app administration features interact with the scheduler. The changes are:

  • Copying an app’s database will no longer copy the contents of the scheduler
  • Restoring an app’s database will not restore the scheduler unless “Scheduler” is explicitly selected

We’ve found that copying the contents of the scheduler along with an app leads to a lot of confusion and issues (such as backup copies of apps running workflows that email or bill users!) Our estimate is that the majority of the time, people copying an app aren’t even aware that the schedule is being copied, and wouldn’t want it to be if they were aware.

If there’s demand for being able to copy both the database and the scheduler, we’ll consider adding it back as an opt-in feature; it certainly shouldn’t be the default.

Likewise, when restoring a database to a previous point in time, our code previously restored the scheduler if “All types” was selected, but this is rarely what users are trying to do. There’s still an option to restore the scheduler by selecting “Scheduler” as the “Data type to restore”, but restoring the scheduler and restoring the app are two separate operations.

We’ve also fixed some bugs with scheduler restoring in calculating what time to run restored tasks at. We now run tasks relative to when they would have been run at the time we are restoring to. For instance, if it is 7 pm, and there was a task that ran at 4 pm, and we restore the scheduler to 3 pm, that task will be scheduled to run at 8 pm: that’s because at 3 pm, that task was scheduled to run in an hour, so we schedule it to run in an hour from the present time. (The previous behavior before this change was buggy and inconsistent, with different tasks being restored to different times).

One final note: this was true before as well, but when we’re restoring the scheduler to a previous state, we pause it while the restore is going on: tasks won’t run until the restore is complete. Now that we don’t restore the scheduler unless explicitly selected, a normal “All Types” restore will not result in the scheduler being paused.

5 Likes

Does this mean that, if we have scheduled batch runs at specific times, and restore from a backup, we have to manually either:
a) adjust all the schedules back to the specific times, or
b) recreate all the schedules?

Thanks for the detailed explanation @josh.

Yes, if you restore the scheduler, unless you’re careful to restore to a discrete interval relative to the time of day you run your tasks, you can inadvertently shift them to run at a different time of day.

In general we really don’t have good features around running things at a specific time of day — the recurring task feature is built around the notion of running things “every so often”. I’ve noted this as an area where we could add features to make apps that care about the exact time that tasks run easier to build.

2 Likes

As Bubble grows, I think a more robust scheduler will help. Most enterprise systems have scheduling systems that allow you to select specific times (daily, weekly, monthly at 3:00pm) or intervals (every 1 min, 5 min, 30 min, 1 hour, 1 day, etc.).

Examples:
https://docs.bmc.com/docs/display/public/ars81/Creating+escalations
https://docs.servicenow.com/bundle/london-platform-administration/page/administer/reference-pages/task/t_ScheduleAScriptExecution.html

1 Like