mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-10 17:22:17 +03:00
acfb844852
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