Prisma throws P3011 when you try to mark a migration as rolled back even though it never ran — the CLI only allows `migrate resolve --rolled-back` on migrations that failed during execution.
P3011 means that Prisma already knows this migration was never applied, so there is nothing to revert. The `migrate resolve --rolled-back <name>` command is only valid for migrations that ran but stopped with an error; it toggles the `_prisma_migrations` record from `failed` to `rolledBack`. If the migration never reached the database (either it was newly created or you pointed at the wrong database), Prisma refuses the rollback because it would leave the migration history inconsistent. Use `prisma migrate status` or query `_prisma_migrations` to see whether the migration has `applied_steps_count > 0` or a `failed_at` timestamp before you attempt to resolve it.
Ask Prisma about the status of the offending migration with npx prisma migrate status --schema prisma/schema.prisma. If you prefer SQL, query the migrations table directly:
SELECT migration_name, applied_steps_count, finished_at, status, failed_at
FROM "_prisma_migrations"
WHERE migration_name = '20220714121901_add_profile';If applied_steps_count is 0 and failed_at is null, the migration never touched the database and cannot be marked as rolled back.
If your migration was created locally but never applied, there is no “rollback” to run. Delete the folder inside prisma/migrations/<timestamp>_name, then rerun npx prisma migrate dev (or generate a fresh migration with npx prisma migrate diff/npx prisma migrate dev --name <new>). This keeps the history in sync without touching _prisma_migrations.
When a migration fails to apply, _prisma_migrations records failed_at. That is the only time prisma migrate resolve --rolled-back <name> should be used. Double-check the row before running the command, then execute:
npx prisma migrate resolve --rolled-back 20220714121901_add_profileIf the migration is still marked as failed, this command clears the failure and allows the next deployments to start from scratch.
Prisma does not generate automatic down migrations. To undo a schema change that already succeeded, author a new migration that puts the schema back in the desired state (for example, drop the column or revert the default). Alternatively, use npx prisma migrate diff --from-schema-datasource --to-schema-datamodel --script > rollback.sql to craft manual SQL and update _prisma_migrations rows so the CLI stays aware of the history.
The migrate resolve command is documented to operate on failed migrations only, so it will always throw P3011 when the history table records no failure. Production troubleshooting guides still recommend resolving failed migrations by marking them as rolled back so you can reapply them, but the migration must actually have failed first. If you keep hitting P3011 after confirming the row exists, verify that DATABASE_URL points to the environment you expect; running the command against the wrong database often looks like an un-applied migration.
P6005: Invalid parameters (Pulse)
How to fix "P6005: Invalid parameters (Pulse)" in Prisma
P2011: Null constraint violation on the field
How to fix "P2011: Null constraint violation" in Prisma
P2009: Failed to validate the query: {validation_error}
How to fix "P2009: Failed to validate the query" in Prisma
P2007: Data validation error
How to fix "P2007: Data validation error" in Prisma
P1013: The provided database string is invalid
The provided database string is invalid