Run migrations before starting workers and the backup scheduler #87

New issue

Closed

opened 2026-07-15 19:49:57 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-07-15 19:49:57 +00:00

Contributor

Severity: Medium · Confidence: High · Effort: XS · Category: ops

Evidence

api/src/index.ts:17-27 - workers + startBackupScheduler() called before await runMigrations() at :29; the .catch at :27 swallows errors.
api/src/services/backup.ts:461-468 - startBackupScheduler queries backup_destinations at startup.

Problem
On a first-ever boot the schema isn't applied yet, so startBackupScheduler queries a non-existent table; the error is swallowed and the schedule silently never registers until a later restart. More generally, workers begin consuming jobs against a possibly-unmigrated schema.

Impact
Backup scheduling silently disabled on fresh installs; latent races on deploys that add columns.

Fix
await runMigrations() first, then start workers and schedulers.

Acceptance criteria

On a clean database, the backup schedule registers on first boot.

Related: F-08 (shutdown).

Filed from the 2026-07-15 codebase audit. Full report: docs/.internal/report-2026-07-15.md (gitignored).

**Severity:** Medium · **Confidence:** High · **Effort:** XS · Category: ops **Evidence** - `api/src/index.ts:17-27` - workers + `startBackupScheduler()` called before `await runMigrations()` at :29; the `.catch` at :27 swallows errors. - `api/src/services/backup.ts:461-468` - `startBackupScheduler` queries `backup_destinations` at startup. **Problem** On a first-ever boot the schema isn't applied yet, so `startBackupScheduler` queries a non-existent table; the error is swallowed and the schedule silently never registers until a later restart. More generally, workers begin consuming jobs against a possibly-unmigrated schema. **Impact** Backup scheduling silently disabled on fresh installs; latent races on deploys that add columns. **Fix** `await runMigrations()` first, then start workers and schedulers. **Acceptance criteria** - [ ] On a clean database, the backup schedule registers on first boot. Related: F-08 (shutdown). --- _Filed from the 2026-07-15 codebase audit. Full report: `docs/.internal/report-2026-07-15.md` (gitignored)._

claude-bot added this to the v7.1.0 - Core hardening & security milestone

2026-07-15 19:49:57 +00:00

claude-bot added the

bug

label

2026-07-15 19:49:57 +00:00

rbrooks referenced this issue from a commit

2026-07-16 21:34:18 +00:00

fix(v7.1): wave 3 — backup recovery & process lifecycle (#87, #84, #85, #86)

claude-bot commented

2026-07-16 21:47:25 +00:00

Author

Contributor

Fixed in b640072 (v7.1.0 wave 3).

api/src/index.ts boot order is now migrate → workers → scheduler → listen. await runMigrations() moved above every startX() call and startBackupScheduler(), so the schema is guaranteed to exist before the scheduler queries backup_destinations and before any worker consumes a job against a possibly-unmigrated schema.

Acceptance criteria:

On a clean database, the backup schedule registers on first boot — the scheduler can no longer run before its table exists.

Verified on the dev server: API boots clean, no errors, /health → {"status":"ok"}. CI green (234/234 tests).

Related: #85 (graceful shutdown) landed in the same commit and reworked the same file.

Fixed in `b640072` (v7.1.0 wave 3). `api/src/index.ts` boot order is now **migrate → workers → scheduler → listen**. `await runMigrations()` moved above every `startX()` call and `startBackupScheduler()`, so the schema is guaranteed to exist before the scheduler queries `backup_destinations` and before any worker consumes a job against a possibly-unmigrated schema. **Acceptance criteria:** - [x] On a clean database, the backup schedule registers on first boot — the scheduler can no longer run before its table exists. Verified on the dev server: API boots clean, no errors, `/health` → `{"status":"ok"}`. CI green (234/234 tests). Related: #85 (graceful shutdown) landed in the same commit and reworked the same file.

claude-bot closed this issue

2026-07-16 22:04:31 +00:00

claude-bot referenced this issue

2026-07-16 22:05:06 +00:00

Roadmap: sequence a core-hardening pass before v8 and test the v7 federation trust boundary #92