the agent's prisma migrate diff said the migration was a no-op but migrate deploy created a new migration anyway -...

TL;DR: Nothing lied - the commands measure different things. migrate diff compares your schema.prisma against a database, while migrate deploy compares your migrations folder against the prismamigrations history table. Run prisma migrate status first: it shows pending migration files, which is what deploy will apply regardless of what diff said.

the agent's prisma migrate diff said the migration was a no-op but migrate deploy created a new migration anyway - the dry-run lied

1. Run the command that answers the deploy question, not the diff question.

npx prisma migrate status

Expected: a list of pending migrations (files on disk not yet in the history table), or a clean bill of health. Pending entries here are exactly what deploy will apply.

2. Compare the three sources of truth side by side: the migrations folder on disk, the prismamigrations table, and the live schema.

ls prisma/migrations
SELECT migration_name FROM _prisma_migrations ORDER BY started_at;

Expected: you can point at the specific migration file that is on disk but missing from history - that is the one deploy wants to apply.

3. Understand why diff said no-op: the live schema already matches schema.prisma (maybe someone applied the change manually, or the database was baselined). Diff compares schema to database, so it sees nothing to do.

Expected: you can explain the no-op in one sentence: the schema matches the database, but the history table is behind the folder.

4. Decide: if the schema change is genuinely already in the database, mark the pending migration as applied without re-running it (resolve), or let deploy apply it if the database actually needs it. Then run migrate deploy.

Expected: migrate status goes clean and deploy reports nothing to apply, or it applies exactly the pending files.

5. Going forward, run migrate status before trusting diff output in automation, and never treat diff as a pre-deploy check.

Expected: your pipeline checks status (folder vs history) for deploy decisions and uses diff only for generating new migration SQL.

Use this when

• prisma migrate diff says no-op but migrate deploy applies migrations
• You need to understand what prisma migrate status is telling you
• The migrations folder and the database history disagree
• A dry-run style check and the real deploy seem to contradict each other

Not for this skill when

• migrate dev created a new migration file unexpectedly - that is dev-workflow behavior, check who ran it
• The database was never baselined and history is empty on an existing database - that needs a baseline, not a status check
• Shadow database creation fails in CI - that is a P3014 permissions problem, separate skill
• You are comparing two schema files rather than schema versus database - diff is the right tool there

Variant phrasings

• prisma migrate diff no-op but deploy runs migrations
• prisma dry run lied, deploy did something anyway
• difference between prisma migrate diff and migrate deploy
• prisma migrate status shows pending but diff says nothing to do

Why it happens

Prisma has two separate comparisons and only one of them matters at deploy time. migrate diff renders the SQL that would sync a schema file to a database - a schema-to-database question. migrate deploy applies pending migration files by comparing the migrations folder to the history table - a folder-to-history question. A database can match the schema file (diff: no-op) while the history table is behind the folder (deploy: work to do), for example after a manual schema change or a baselined database. Both commands are correct; they just answer different questions.

Edge cases

• migrate deploy never creates migration files. If a new file appeared in prisma/migrations, something ran migrate dev (or a teammate committed it) - check git history.
• Resolving a pending migration as already-applied without verifying the database really has the change will corrupt the history. Verify first, every time.
• In CI, the shadow database used by diff needs create-database privileges. A diff failure there is environmental, not a schema signal.
• Drift detection in migrate dev is a third comparison (schema vs database, dev-oriented). Do not mix its output into deploy decisions either.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstiwPVeIt_w6L7ugtOfsSJw