Skip to content

fix(db): make earliest migrations idempotent (0002/0011/0012) - #486

Closed
jonathonbyrdziak wants to merge 1 commit into
mainfrom
fix/migration-idempotency
Closed

fix(db): make earliest migrations idempotent (0002/0011/0012)#486
jonathonbyrdziak wants to merge 1 commit into
mainfrom
fix/migration-idempotency

Conversation

@jonathonbyrdziak

Copy link
Copy Markdown
Contributor

Problem

DatabaseManager.runMigrations fails fast — any error in a migration's up SQL is rethrown and aborts DB init (DatabaseManager.ts:138). Migrations 0002, 0011, 0012 are the earliest ones and predate the IF NOT EXISTS convention that every migration from 0009 onward already follows.

On any install where the tables/columns already exist but aren't recorded in sulla_migrations, these three re-run their up and throw 42P07 (duplicate table) / duplicate column — bricking boot. That scenario is exactly the migration-table backfill/seed path under investigation (pre-tracking installs, restored DBs, or a manually seeded sulla_migrations).

Fix

  • 0002CREATE TABLE agent_awarenessCREATE TABLE IF NOT EXISTS
  • 0011CREATE TABLE sulla_settingsCREATE TABLE IF NOT EXISTS; also fixes a latent down-migration bug — it dropped settings instead of sulla_settings
  • 0012ADD COLUMN "cast"ADD COLUMN IF NOT EXISTS; down → DROP COLUMN IF EXISTS

Audit

Swept all 22 registered migrations: these three are the only non-idempotent DDL. 0009/0014/0024 already use ADD COLUMN IF NOT EXISTS; 0010 indexes use CREATE INDEX IF NOT EXISTS; no CREATE TYPE/enum. Registry legitimately stops at 0028 (CRM 0029–0036 were added then removed in fb5e8017d).

Verification

  • Transpile-checked (tsc --isolatedModules, exit 0) — template literals balanced.
  • Ran all three fixed up statements against the live DB where the objects already exist → all succeed as no-ops. Pre-fix these would throw. Idempotency proven.

Schema-only, no user data (complies with the no-user-data-in-migrations rule).

🤖 Generated with Claude Code

The migration runner (DatabaseManager.runMigrations) fails fast: any error
in a migration's `up` SQL is rethrown and aborts DB init. Migrations 0002,
0011, and 0012 predate the `IF NOT EXISTS` convention that every migration
from 0009 onward follows, so on any install where the tables/columns already
exist but aren't recorded in sulla_migrations (pre-tracking installs, restored
DBs, or a backfilled/seeded migrations table) they throw 42P07 / duplicate
column and brick boot.

- 0002: CREATE TABLE agent_awareness -> IF NOT EXISTS
- 0011: CREATE TABLE sulla_settings -> IF NOT EXISTS; also fix down migration
  which dropped the wrong table (`settings` -> `sulla_settings`)
- 0012: ADD COLUMN "cast" -> ADD COLUMN IF NOT EXISTS; down -> DROP COLUMN IF EXISTS

Verified: all three fixed `up` statements run clean against already-existing
objects on the live DB (previously would error). Transpile-checked.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@jonathonbyrdziak

Copy link
Copy Markdown
Contributor Author

PR opened: #503 (autonomous heartbeat cycle). Fix applied and verified in an isolated worktree off main; see the PR for the verification run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant