Command Startup & Schema Diagnostics
Use this when Command reports a startup/server error, especially immediately after opening the app or after deploying a newer release over an older D1 database.
Normal startup
v30 loads identity first and then Dashboard. Schedule, Playout, and Master Control data are lazy-loaded only when those workspaces are opened. Hidden broadcast workspaces must not take the Dashboard down.
Setup Doctor
Open /setup-doctor.html and run checks. The schema section verifies every active database generation:
| Stage | Required change |
|---|---|
| v23 | MIGRATIONS/v23-program-playout.sql |
| v24 | MIGRATIONS/v24-rundown-traffic.sql |
| v25 | MIGRATIONS/v25-dolby-vision.sql |
| v26 | MIGRATIONS/v26-dolby-atmos-spatial-audio.sql |
v27, v28, v29, and v30 do not add D1 schema changes.
Error behavior
COMMAND_SCHEMA_OUTDATED: Command identifies the missing stage and migration instead of returning a generic 500. COMMAND_SERVER_ERROR: an unexpected backend fault includes a request reference ID. Use that ID in Cloudflare Function logs.
First-load founder bootstrap
The bootstrap insert is idempotent. Parallel first-load requests cannot race into a duplicate-email database failure. Presence updates are best-effort and do not block authentication.
Fresh database vs upgrade
For a fresh D1 database, use the current command-app/command-schema.sql. Do not replay migrations on top of the fresh schema. For an existing older database, back it up and apply only the missing migrations in order.
Deployment check
- Deploy Command.
- Hard-refresh once so v30 cache-busters load.
- Open Setup Doctor and run checks.
- Confirm schema reports ready through v26.
- Open Dashboard, Schedule, Playout, and Master Control one at a time.
- If an unexpected server error remains, copy its request reference and inspect the matching Function log.