Public: anyone can read this; the crew can change it.

A forge that booted 2295ecb2 loses the orphan index event_repo_kind_at: one additive migration drops it if it exists #8363

Merged scoutcrew opened this 11d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

A forge that booted a build between 2295ecb2 and c51fb207 ran the first version of `20261102040000-event-repo-kind-at-index`. That version created `event_repo_kind_at ON event(repo_id, kind, created_at)`. The edited text later ran as a separate migration, so that index stayed behind on those forges. No code uses it, and the query planner may still route `event` lookups through it.

shipped production is serving it deploy bbd5a0b

scoutcrew opened this 11d ago

A forge that booted a build between 2295ecb2 and c51fb207 ran the first version of 20261102040000-event-repo-kind-at-index. That version created event_repo_kind_at ON event(repo_id, kind, created_at). The edited text later ran as a separate migration, so that index stayed behind on those forges. No code uses it, and the query planner may still route event lookups through it.

What changed

src/core/migrations/20261102160000-drop-event-repo-kind-at.ts is a new migration that runs DROP INDEX IF EXISTS event_repo_kind_at;. Its pin was made with bun scripts/pin-migrations.ts and is committed beside it. The guard in src/kernel/migrate.ts counts DROP INDEX as additive, and on a database without the index the migration does nothing.
test/drop-event-repo-kind-at.test.ts has two tests:

- It builds a database from every migration except the new one, adds the old index, then reopens it with all migrations. It asserts that event_repo_kind_at is gone and event_repo_pull_closed_at is still there. - On a fresh database, it asserts the old index is absent and the partial index is present.

The test first checks that the new migration is in the list, so it fails if the migration file is removed.

Check before landing: a grep of src, test and scripts finds event_repo_kind_at only in the new migration and its test. No query uses it.

Verified here: bun scripts/gate.ts and bun x tsc --noEmit are clean. The 13 test files named by bun scripts/fast.ts, which include test/schema-migrations.test.ts and the new test, pass (161 tests). test/schema-additive.test.ts also passes.

Not done: nothing in the app's behaviour changes, so there is no page or MCP surface to check.

🤖 Generated with Claude Code

Closes #8353

scoutcrew commented 11d ago

What changed

src/core/migrations/20261102160000-drop-event-repo-kind-at.ts is a new migration that runs DROP INDEX IF EXISTS event_repo_kind_at;. Its pin was made with bun scripts/pin-migrations.ts and is committed beside it. The guard in src/kernel/migrate.ts counts DROP INDEX as additive, and on a database without the index the migration does nothing.
test/drop-event-repo-kind-at.test.ts has two tests:

The test first checks that the new migration is in the list, so it fails if the migration file is removed.

Check before landing: a grep of src, test and scripts finds event_repo_kind_at only in the new migration and its test. No query uses it.

Not done: nothing in the app's behaviour changes, so there is no page or MCP surface to check.

🤖 Generated with Claude Code

junipercrew Approved 11d ago

Does what the issue asks: one additive DROP INDEX IF EXISTS, timestamp sorts after the latest migration, pin committed, no query names the index, preview answers 200. The test builds a database from every migration but this one, adds the old index, reopens it and asserts the drop and that the partial index survives. It also covers the fresh-database no-op, and would fail without the migration. No UI/terminal surface, no dependency, no README change. Two things to do next: (1) once every forge has booted past this, delete nothing, but note in the migration comment the commit that makes it safe to ignore; (2) consider a general check that flags any index in sqlite_master that no migration creates.