migrate down undoes the last integration's newest migration, not the most recently applied one #242

New Issue

2026-10-20T07:06:14Z

cgalo5758 commented

2026-10-20 07:06:14 +00:00

What happens

member-console migrate down describes itself as "Rollback the most recently applied migration". It rolls back one step of the last migration stream in source order that has any applied migration: the last installed integration's stream, today Discourse's, then the other integrations, then domains, and core only when every other stream is empty. After a release that adds only a core migration, migrate down leaves that migration in place and runs the Down section of Discourse's newest migration instead, which rewrites every orphaned user link as conflict.

What should happen

The command undoes what its help says. Either it rolls back the migration applied last across all streams, which each stream's ledger records with a timestamp, or it takes the stream as an argument and refuses to run without one. Its help text and docs/database-management.md state which.

Where

cmd/migrate.go (the help text), internal/db/migrations.go (RollbackMigration), docs/database-management.md ("Rollback").

Why it matters

An operator undoing a bad release with the documented command keeps the migration they meant to undo and runs another stream's Down section, some of which rewrite data.

### What happens `member-console migrate down` describes itself as "Rollback the most recently applied migration". It rolls back one step of the last migration stream in source order that has any applied migration: the last installed integration's stream, today Discourse's, then the other integrations, then domains, and core only when every other stream is empty. After a release that adds only a core migration, `migrate down` leaves that migration in place and runs the Down section of Discourse's newest migration instead, which rewrites every `orphaned` user link as `conflict`. ### What should happen The command undoes what its help says. Either it rolls back the migration applied last across all streams, which each stream's ledger records with a timestamp, or it takes the stream as an argument and refuses to run without one. Its help text and `docs/database-management.md` state which. ### Where `cmd/migrate.go` (the help text), `internal/db/migrations.go` (`RollbackMigration`), `docs/database-management.md` ("Rollback"). ### Why it matters An operator undoing a bad release with the documented command keeps the migration they meant to undo and runs another stream's Down section, some of which rewrite data.

cgalo5758 added the

kind

bug

area/ops labels 2026-10-20 07:06:14 +00:00

cgalo5758 referenced this issue from a commit

2026-10-31 09:25:07 +00:00

Archive the advisory key families change

Sign in to join this conversation.