Two files both claimed migration version 135:
135_connection_runtime_state.sql (#9449, landed 2026-08-07) and
135_migrate_model_capability_max_token.sql (#8908, landed 2026-08-05).
#9449 branched before #8908 merged and never got renumbered before
landing on release/v3.8.50.
This is not cosmetic: getMigrationFiles() throws "Migration version
collision detected" the moment ANY code path first touches the
database (getDbInstance() -> runMigrations()), which means a
completely fresh install/deploy from this branch cannot even boot —
confirmed live against a freshly built container while testing
unrelated live-verification tooling.
Renumbered the later-landing file to 140 (the next free slot) and
added the matching isSchemaAlreadyApplied("140") retroactive guard in
migrationRunner.ts, so a DB that already ran this migration under the
old 135 number isn't treated as needing a fresh application. This
matches the established pattern already used for the prior 135/136 ->
137/138 renumber in the same file (also caused by the same recurring
branch-before-merge numbering race).
Test plan:
- TDD: new tests/unit/migration-135-numbering-collision.test.ts (2/2)
— spins up a hermetic fresh DB and confirms getDbInstance() applies
every real on-disk migration without throwing, plus confirms both
formerly-135 migrations' effects are present. Confirmed failing
(reproducing the exact live crash) with the pre-fix colliding
filenames restored, passing after the rename.
- npm run typecheck:core — clean
- npm run lint — clean
- npm run check:file-size — clean (migrationRunner.ts rebaselined
1084->1094 for the new guard case)
- Full migration-runner + migration-numbering test suites (64 tests
across 6 files) — all pass, no regressions
acfb844852