Skip to content

feat(core): re-run a published version's migration when its revision is bumped - #3890

Merged
dr-bonez merged 1 commit into
masterfrom
feat/migration-revision
Sep 2, 2026
Merged

feat(core): re-run a published version's migration when its revision is bumped#3890
dr-bonez merged 1 commit into
masterfrom
feat/migration-revision

Conversation

@dr-bonez

@dr-bonez dr-bonez commented Sep 2, 2026

Copy link
Copy Markdown
Member

Why

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 has committed a version keeps that version's up() 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

  • VersionT gains migration_revision() (default 0). commit records the revision it applied in serverInfo.latestMigrationRevision.
  • pre_init's Ordering::Equal branch re-runs up() + commit() when the stored revision differs from the running binary's. commit re-queues the version in postInitMigrationTodos, so post_up() runs again too.
  • A db without the field reads as revision 0 (#[serde(default)]); Public::init seeds a fresh install at Current's revision so it never migrates itself on first boot.
  • 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 idempotent (the ALPN, port-80, name and hostname steps each no-op on an already-migrated db).
  • Docs: the trait doc and VERSION_BUMP.md state the contract — bumping a revision requires the migration to be idempotent with its previous revision, since the re-run happens on a db the earlier up() already transformed, never on the pre-migration shape.
  • Regenerated 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)
  • bindings regenerated with CI's feature set (test,dev,unstable); only ServerInfo.ts changed
  • npm run build:core && npm run check:ui && npm run check:setup clean
  • pinned rustfmt + prettier clean

…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.
@dr-bonez
dr-bonez merged commit 98734ec into master Sep 2, 2026
32 checks passed
@dr-bonez
dr-bonez deleted the feat/migration-revision branch September 2, 2026 20:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants