feat(core): re-run a published version's migration when its revision is bumped - #3890
Merged
Conversation
…is bumped Every master push republishes `Current` to alpha under the same version number, but `pre_init` only migrates a db whose recorded version is behind `Current`. A server that committed a version keeps that version's `up()` as it was on the day it updated: 0.4.0.2 has gained the ALPN rewrap, the server-name drop, and the hostname repair since alpha boxes first took it, and none of that ran on them. `VersionT` gains `migration_revision()` (default 0). `commit` records the revision it applied in `serverInfo.latestMigrationRevision`, and the `Ordering::Equal` branch of `pre_init` re-runs `up()` and `commit()` when the stored revision differs from the running binary's; `commit` re-queues the version in `postInitMigrationTodos`, so `post_up()` runs again too. Because the re-run happens on a db the earlier revision already migrated, a bumped migration must be idempotent with its previous revision — documented on the trait and in VERSION_BUMP.md. 0.4.0.2 is bumped to revision 1 so every server already on it applies the steps it missed once; its `up()` was already written to be idempotent. A db without the field reads as revision 0, and `Public::init` seeds a fresh install at `Current`'s revision so it never migrates itself on first boot.
Dominion5254
approved these changes
Sep 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Every master push republishes
Currentto alpha under the same version number, butpre_initonly migrates a db whose recorded version is behindCurrent. A server that has committed a version keeps that version'sup()as it was on the day it updated. 0.4.0.2's migration has changed three times since alpha boxes first took it — the ALPN rewrap (#3777), the server-name drop and hostname repair (#3791) — and none of that has run on them.What
VersionTgainsmigration_revision()(default0).commitrecords the revision it applied inserverInfo.latestMigrationRevision.pre_init'sOrdering::Equalbranch re-runsup()+commit()when the stored revision differs from the running binary's.commitre-queues the version inpostInitMigrationTodos, sopost_up()runs again too.0(#[serde(default)]);Public::initseeds a fresh install atCurrent's revision so it never migrates itself on first boot.up()was already idempotent (the ALPN, port-80, name and hostname steps each no-op on an already-migrated db).VERSION_BUMP.mdstate the contract — bumping a revision requires the migration to be idempotent with its previous revision, since the re-run happens on a db the earlierup()already transformed, never on the pre-migration shape.ServerInfo.ts; the UI mock carries the new field.No changelog entry: 0.4.0.2 is untagged, and the only user-visible effect is that alpha/beta servers receive fixes already listed under it.
Verification
cargo test -p start-core --features=test version::— 31 passed, including two new tests (a_db_that_predates_revisions_reads_as_revision_zero,commit_records_the_revision_of_the_migration_it_applied)test,dev,unstable); onlyServerInfo.tschangednpm run build:core && npm run check:ui && npm run check:setupclean