Skip to content

db: fail loudly when two migrations share a version number - #233

Open
constkolesnyak wants to merge 1 commit into
ClickHouse:mainfrom
constkolesnyak:fix/duplicate-migration-guard-v2
Open

db: fail loudly when two migrations share a version number#233
constkolesnyak wants to merge 1 commit into
ClickHouse:mainfrom
constkolesnyak:fix/duplicate-migration-guard-v2

Conversation

@constkolesnyak

Copy link
Copy Markdown
Contributor

What

Add a guard in the migration runner that raises an error if two migration modules use the same version number, instead of silently skipping or applying one.

Also adds a dedicated test file for the migration runner (tests/test_migrations_runner.py).

Why

Silent duplicate version handling has caused subtle production issues — this guard surfaces the mistake immediately on startup.

Rebased on current upstream/main (2026-07-30).

run_migrations skips anything at or below the recorded schema version, so
if two files claim the same number one silently wins and the other never
runs — on every database, forever, with no error. It surfaces much later
as a missing column or index, and which of the two is missing depends on
filesystem iteration order, so it reproduces on some machines and not
others.

discover_migrations now raises on a collision, naming both files. Failing
at import is the lesser evil: the collision is a packaging mistake caught
in seconds once it is named, whereas a silently skipped migration costs
hours and can corrupt data in the meantime.

Adds tests/test_migrations_runner.py (there were none), including a
regression check that the real on-disk migration set has no duplicates —
so a collision introduced later fails in CI rather than at a user startup.

113 tests pass.
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