Rollback and recovery
When to use rollback, when to prefer a forward fix, and how to recover from common migration-state failures.
Rollback and recovery
Rollback exists, but it is not the default answer to every production problem.
Prefer forward fixes for shared databases
If a migration was already applied to a shared environment, a new forward migration is usually safer than mutating history or repeatedly rolling backward and forward.
Use rollback when:
- the migration just landed and the blast radius is limited
- the rollback path is reviewed and understood
- the before-state is still valid for current application code
Rollback command
migrate rollback remains available, but treat it as a recovery tool rather than the default rollout workflow.
dart run comon_orm migrate rollback \
--schema schema.prisma \
--from prisma/migrationsRollback uses:
- local
before.prismaartifacts when available - recorded schema snapshots from
_comon_orm_migrationswhen local files are missing
checksum-mismatch
This means the migration artifact on disk no longer matches what the database recorded.
Safe response:
- stop before applying anything new
- restore the checked-in artifact if it was edited locally
- if the checked-in history is already wrong, create a new forward migration instead of editing old applied directories
Applied migration missing locally
If migrate status reports applied-migration-missing-locally, the database history references a migration directory that is not present on disk.
Safe response:
- recover the missing migration directory from version control if possible
- verify
before.prisma,after.prisma, andmigration.sql - run
migrate statusagain before applying anything else
Missing snapshots in older history
If the history table lacks older schema snapshots, rollback can be more limited.
That is a signal to:
- recover old artifacts from version control
- avoid blind rollback on important environments
- prefer a forward migration that restores the desired state explicitly
History repair
If the database state is correct but the recorded migration state is wrong, use migrate resolve instead of forcing another schema mutation.
Typical commands:
dart run comon_orm migrate resolve --applied 20260318_add_post_status
dart run comon_orm migrate resolve --rolled-back 20260318_add_post_statusWarning-gated rollback
Rollback stops on warnings by default just like other mutation commands.
Use --allow-warnings only after you review the implied data loss or rebuild consequences.