Sync staging database from production every three days

[cquil11]

Summary

• add a scheduled GitHub Actions workflow that restores the Neon staging branch from the default production branch every three calendar days at 4:00 AM America/Chicago time
• wait for Neon to report the restored branch ready, then invalidate the protected staging deployment cache
• add a shared concurrency lock so scheduled restores cannot race the existing staged-results ingest workflow
• support manual workflow runs for on-demand synchronization

Why

The staging database accumulates staged benchmark runs and can drift from production. Periodically replacing it from the production head gives staging a predictable, complete baseline while preserving the existing production branch and connection endpoints.

GitHub cron does not provide a true every-N-days interval: */3 in the day-of-month field resets at month boundaries. The workflow therefore triggers daily at 4:00 AM Central and uses an epoch-day modulo guard to perform the restore on an exact three-calendar-day cadence. timezone: America/Chicago keeps the wall-clock time at 4:00 AM across daylight-saving changes.

Validation

• actionlint .github/workflows/stage-results.yml .github/workflows/sync-staging-database.yml
• uvx --exclude-newer P1D zizmor@latest --strict-collection --pedantic --no-ignores .github/workflows/stage-results.yml .github/workflows/sync-staging-database.yml
• pre-commit formatting, lint, and TypeScript checks
• no live database restore was performed
• full E2E tests were not run because the change is limited to GitHub Actions workflows

---

Note

Medium Risk
Periodically wipes and replaces the shared staging database via Neon restore APIs; production is guarded, but a bad restore or race would disrupt staging data and ingest.

Overview
Adds a scheduled workflow that restores the Neon staging branch from production every three calendar days (daily 4:00 AM Central trigger with an epoch-day guard), then invalidates the staging site cache. Manual workflow_dispatch runs bypass the cadence check.

Locks stage-results and the new sync workflow behind a shared staging-database-maintenance concurrency group so restores and staged-run ingest cannot overlap.

^{Reviewed by Cursor Bugbot for commit ea47d2d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
inferencemax-app	Building	Preview	Aug 12, 2026 1:43pm

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit ea47d2d. Configure here.}

[cursor]

Concurrency drops pending maintenance runs

High Severity

The shared staging-database-maintenance concurrency group omits queue: max, so GitHub keeps only one pending run and cancels any earlier waiter when another arrives. A pending scheduled sync can be dropped, and the epoch-day guard will not retry until three days later. Pending stage-results runs can also be cancelled with no completion dispatch back to the source repo.

Additional Locations (1)

• .github/workflows/stage-results.yml#L42-L47

 

^{Reviewed by Cursor Bugbot for commit ea47d2d. Configure here.}