You've read it exactly right. SCHEMA_HEAD is the head of the migrations folder shipped in the build (ScriptDirectory.get_current_head()), create() stamps it into the manifest, and restore() refuses when manifest.alembic_head != (expected_head or SCHEMA_HEAD) → BackupSchemaMismatchError. So the guard is build-vs-manifest, and the restore path never reads alembic_version from the target DB. Your rolling-upgrade window is the real gap: the old pod can restore into a DB one revision ahead. Reading version_num inside restore() (the same query readiness.py runs) and refusing on a mismatch would close it — noting that for the v0.2.0 write-up. Thank you for the precise repro.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You've read it exactly right.
SCHEMA_HEADis the head of the migrations folder shipped in the build (ScriptDirectory.get_current_head()),create()stamps it into the manifest, andrestore()refuses whenmanifest.alembic_head != (expected_head or SCHEMA_HEAD)→BackupSchemaMismatchError. So the guard is build-vs-manifest, and the restore path never readsalembic_versionfrom the target DB. Your rolling-upgrade window is the real gap: the old pod can restore into a DB one revision ahead. Readingversion_numinsiderestore()(the same queryreadiness.pyruns) and refusing on a mismatch would close it — noting that for the v0.2.0 write-up. Thank you for the precise repro.