You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A timing issue could cause daily backups to be silently skipped for every project due in a 10-minute scheduling window. Backup scheduling now retries and recovers automatically.
The job that schedules daily backups checks which projects are due on a strict time budget. Under database replica lag, that check could exceed its budget, and with no retry in place the whole 10-minute scheduling window was silently dropped fleet-wide — any project due in that window missed its backup for the day.
Backup scheduling now retries on failure, anchored to its original scheduled window so a retry can't skip or re-scan the wrong projects, reads eligibility from the primary database instead of a replica to avoid the lag that triggered the timeout, and no longer lets a project in an unroutable region crash the whole scheduling run. A companion fix (supabase/platform#36499) addresses the underlying slow query.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
A timing issue could cause daily backups to be silently skipped for every project due in a 10-minute scheduling window. Backup scheduling now retries and recovers automatically.
The job that schedules daily backups checks which projects are due on a strict time budget. Under database replica lag, that check could exceed its budget, and with no retry in place the whole 10-minute scheduling window was silently dropped fleet-wide — any project due in that window missed its backup for the day.
Backup scheduling now retries on failure, anchored to its original scheduled window so a retry can't skip or re-scan the wrong projects, reads eligibility from the primary database instead of a replica to avoid the lag that triggered the timeout, and no longer lets a project in an unroutable region crash the whole scheduling run. A companion fix (supabase/platform#36499) addresses the underlying slow query.
Affected products: Database, Platform
Authored by @hunleyd
All reactions