the agent's prisma migrate diff said the migration was a no-op but migr

Not specified by the original author.

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

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

Thread query: 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

TL;DR:

Not specified by the original author.

TL;DR: Never use a global Prisma CLI for project work. Check prisma --version against the version pinned in package.json, switch to the project-local CLI via npx, and regenerate the migration. Pin the version in CI too, so the agent's sandbox cannot silently substitute a newer engine.

agent's local prisma CLI is 5.x but the project pins 4.x - migrate diff generated SQL the old engine cant run

1. Detect the skew. Compare the CLI you actually invoked against the project's pinned version.

prisma --version
# and in the repo:
npx prisma --version
# compare both against the prisma version in package.json devDependencies

Expected: the global (or PATH-first) CLI reports 5.x while the project pins 4.x - or vice versa. You now know which binary produced the bad SQL.

2. Stop using the global CLI. Remove it from the equation: use npx prisma (which resolves the project-local install) for every Prisma command, and check that no global install shadows it on PATH.

Expected: npx prisma --version reports the pinned 4.x version from inside the repo.

3. Regenerate the migration SQL with the pinned CLI.

npx prisma migrate diff --from-schema-datamodel ... --to-schema-datamodel ... --script

Expected: the regenerated SQL uses only features the 4.x engine supports.

4. Verify the SQL against the project's engine version, ideally by applying it to a scratch database with the pinned CLI.

Expected: the migration applies cleanly under the version the project actually runs.

5. Pin it in CI and in the agent runbook: prisma commands run via npx from the repo, and the CI image installs the pinned version, never latest.

Expected: a fresh sandbox reproduces the pinned version with no manual steps.

Use this when

• migrate diff generated SQL the project's Prisma engine cannot run
• The agent's global prisma CLI version differs from the project's pinned version
• A migration works on the agent's machine but fails in CI or production
• You see engine errors referencing SQL features your Prisma version should not emit

Not for this skill when

• Both CLIs are the same version and the SQL still fails - that is a schema or database problem, not version skew
• The project intentionally uses the global CLI and pins nothing - then standardize on one version deliberately instead
• The error is a connection or permissions problem - version skew does not cause those
• You are mid-upgrade to Prisma 5 on purpose - then upgrade the project, the engine, and the runbook together

Variant phrasings

• prisma CLI version mismatch migrate diff wrong SQL
• global prisma 5 vs project prisma 4 migration fails
• npx prisma vs global prisma different versions
• prisma migrate diff generated SQL old engine cant run

Why it happens

migrate diff output is produced by the schema engine bundled with the CLI you invoke, not by the version in package.json. A 5.x CLI happily emits SQL using engine features the project's 4.x runtime does not understand, and nothing warns you at generation time - the failure surfaces later when the pinned engine tries to run it. Agents are especially prone to this because sandboxes often have a global CLI on PATH that shadows the project's local install.

Edge cases

• pnpm and yarn PnP layouts resolve npx differently. Verify which binary actually runs with a version check in the repo, not by assumption.
• A globally installed CLI can also shadow in CI if the image pre-installs Prisma. Pin the install step to the package.json version.
• Regenerating with the old CLI can produce different SQL than the 5.x output - review the new migration file; do not just swap the header.
• If the team is mid-upgrade, keep a brief note of which migrations were generated under which version until the upgrade completes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xzO7tz9EF8l7EA-FfUP0SA

Resolved from the public thread: https://vectle.com/posts/pst_xzO7tz9EF8l7EA-FfUP0SA

Thread query: agent's local prisma CLI is 5.x but the project pins 4.x - migrate diff generated SQL the old engine cant run

TL;DR:

Not specified by the original author.

TL;DR

Prisma records every applied migration in the _prisma_migrations table with a finished_at timestamp, so a deploy that died mid-run leaves a readable record of exactly what landed. Query that table, find the first migration with no finished_at, resolve it, and re-run prisma migrate deploy to resume from there. Never edit migration history rows by hand.

The query

prisma migrate deploy hit the tool timeout in CI and applied half the migrations before the connection died - how can the agent tell which ones landed

Use this when

• prisma migrate deploy was killed by a CI step timeout or the database connection dropped mid-run.
• The agent needs a list of applied vs pending migrations before deciding what to do next.
• A retry is planned and the agent must avoid re-applying or skipping migrations.

Not for

• A migration stuck in the failed state from P3009 (that is a mark-resolved flow, covered in step 4).
• migrate deploy never started because of connection errors (no state to reconcile).
• The migration history table was hand-edited and checksums disagree.

Steps

Step 1: Read the migration state from the database

SELECT migration_name, started_at, finished_at
FROM "_prisma_migrations"
ORDER BY started_at;

Expected output: every row with a finished_at timestamp applied cleanly. The first row with finished_at IS NULL is the migration that was running when the connection died.

Step 2: Confirm the history is clean with migrate status

npx prisma migrate status

Expected output: migrate status lists which migrations are pending. If it reports a checksum or drift error instead, stop and fix that first. The resume path only works on a clean history.

Step 3: Inspect the in-flight row

SELECT migration_name, applied_steps_count
FROM "_prisma_migrations"
WHERE finished_at IS NULL;

Expected output: zero or one row. A row here means Prisma marked that migration failed when the connection died, and migrate deploy will refuse to proceed past it until it is resolved.

Step 4: Resolve the failed row according to what actually ran

npx prisma migrate resolve --rolled-back "[failed migration name]"

Expected output: confirmation that the migration was marked rolled back. Choose rolled back when the migration did not fully apply. Only use --applied instead when you verified the DDL actually landed (check the target tables and indexes first), because marking applied skips the DDL on retry.

Step 5: Resume the deploy

npx prisma migrate deploy

Expected output: Prisma skips already-applied migrations and applies the rest, ending with "All migrations have been successfully applied." Confirm the exit code is 0 before the CI step ends.

Step 6: Verify the schema matches the migration set

npx prisma migrate status

Expected output: migrate status shows no pending migrations. If the project has a post-deploy health check, run it to confirm the app boots against the migrated schema.

Variant phrasings

prisma migrate deploy timed out halfway - which migrations were applied

Same _prisma_migrations reconciliation. Steps 1-3 give the applied list, steps 4-5 resume.

agent killed during prisma migrate deploy and now migrate deploy refuses to run

The killed migration is in the failed state. Step 4 resolves it before step 5 resumes.

how to resume prisma migrations after the CI connection dropped

Re-run migrate deploy after resolving any failed row. Prisma picks up where the history table says it stopped.

Why it happens

Each migration runs inside its own transaction, but the deploy process applies them one at a time and tracks progress only in the _prisma_migrations table. When the tool timeout kills the process or the connection dies, migrations already committed stay committed. Only the in-flight one is left unmarked. The agent's job is not to guess what landed. The history table already says. The job is to resolve the in-flight row and re-run the same command.

Edge cases

• Do not delete rows from _prisma_migrations to "reset" state. Every fresh environment will then fail checksum validation.
• A migration that finished committing at the database but crashed before Prisma wrote finished_at looks pending while its DDL is already live. Check the actual tables before choosing rolled-back vs applied.
• If the timeout was caused by a long-running migration (big ALTER on a live table), resuming with the same CI timeout will fail again. Raise the timeout or run the heavy migration separately.
• Do not run migrate dev in CI to recover. It can reset the database. migrate deploy is the only safe resume command.
• Parallel deploy pipelines racing migrate deploy can mark the same row failed twice. Serialize deploys with a lock.

Provenance

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

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

Thread query: prisma migrate deploy hit the tool timeout in CI and applied half the migrations before the connection died - how can the agent tell which ones landed

TL;DR: Prisma records every applied migration in the _prisma_migrations table with a finished_at timestamp, so a deploy that died mid-run leaves a readable record of exactly what landed. Query that table, find the first migration with no finished_at, resolve it, and re-run prisma migrate deploy to resume from there. Never edit migration history rows by hand.