agent keeps re-running prisma migrate dev because drift detection flags it

Not specified by the original author.

TL;DR: Stop using migrate dev in the loop - it is an interactive development command that creates a shadow database to detect drift, and in automation it keeps flagging its own shadow as drift. Switch the agent to prisma migrate deploy for applying migrations and prisma migrate diff for inspection. If you must use migrate dev, point it at a disposable dev database it is allowed to reset, never at shared state.

agent keeps re-running prisma migrate dev because drift detection flags its own shadow database as drift

1. Confirm the loop: run prisma migrate status and read the drift report. Expected: it names the shadow database or shows drift that reappears immediately after a successful dev run.

2. Check where migrate dev is pointed: inspect the datasource URL the agent is using. Expected: if it points at a shared, CI, or production-like database, that is the problem - migrate dev wants to reset whatever it touches on drift.

3. Switch the agent's apply step to prisma migrate deploy. Expected: output shows how many migrations it applied (or "No pending migrations to apply"), with no drift prompt and no reset.

4. Use prisma migrate diff for the inspection step the agent was using migrate dev for. Expected: a readable diff of schema changes without creating or resetting any database.

5. Reserve migrate dev for an interactive dev database the agent owns and may reset freely. Expected: drift prompts there are answerable and harmless because the database is disposable.

Use this when

• prisma migrate dev keeps reporting drift and wanting to reset in a loop
• an agent re-runs migrate dev and it never converges
• drift detection flags the shadow database rather than real schema changes

Not for this skill when

• the drift is real (someone hand-edited the database) - resolve the actual schema difference
• migrations fail to apply with SQL errors - that is a migration bug, not drift detection
• you are setting up the very first migration - migrate dev is fine interactively for that

Variant phrasings

• prisma migrate dev drift loop on shadow database
• migrate dev keeps detecting drift after successful run
• prisma drift detection will not settle in CI

Why it happens

migrate dev is built for interactive development: it creates a shadow database, diffs it against your migrations to detect drift, and on drift asks to reset the database. In a headless agent loop there is nobody to answer, and the shadow-database mechanics mean each run can re-detect its own artifacts as drift. migrate deploy skips all of this - it just applies pending migrations, which is what automation actually wants.

Edge cases

• migrate deploy does not create the database or run seed scripts - handle database creation and seeding as separate steps.
• If drift is genuine, migrate deploy still refuses to run until it is resolved - check the prisma migrations table for failed rows first.
• The shadow database needs database-creation privileges; in locked-down environments the shadow creation itself can fail and look like drift.
• Never let an agent run migrate dev against a database with real data - the reset prompt it wants to answer destroys data.

Provenance

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

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

Thread query: agent keeps re-running prisma migrate dev because drift detection flags its own shadow database as drift

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.

Not specified by the original author.

TL;DR: Do not run migrate dev in automation at all - it is an interactive command, and the reset prompt it is waiting on has no safe default answer. Switch the agent to prisma migrate deploy, which applies pending migrations with no prompts. If a dev database genuinely needs resetting, do it as an explicit, separately approved step, never as a side effect of a hung migrate.

prisma migrate dev hung because the agent couldnt answer the interactive reset-the-database prompt - no tty in the sandbox

1. Confirm the hang is the reset prompt: check the process - it is idle, and the drift report from migrate status mentions drift or a needed reset. Expected: prisma migrate status shows drift that explains why dev wanted to reset.

2. Kill the hung process - it will never proceed without input. Expected: the process exits and the database is untouched (the prompt appears before any destructive action).

3. Replace the agent's apply step with prisma migrate deploy. Expected: it prints which migrations it applied (or "No pending migrations to apply") and exits on its own, no prompt.

4. If the database actually needs a reset for development, make it explicit: drop and recreate the dev database as its own step, then run migrate deploy against the empty database. Expected: a clean schema with no interactive prompt anywhere in the flow.

5. Guard the agent loop: fail the step fast if any command waits on stdin (redirect stdin from an empty source so a prompt errors instead of hanging). Expected: future prompt-waits surface as immediate errors with a clear message, not long stalls.

Use this when

• prisma migrate dev hangs in a sandbox, CI, or any headless environment
• the agent cannot answer the reset-the-database prompt
• a migrate step stalls with zero output

Not for this skill when

• you are developing interactively with a real terminal - migrate dev is fine there, just answer the prompt
• migrate deploy reports failed migrations - resolve those in the migrations table first
• the database connection itself is broken - fix connectivity

Variant phrasings

• prisma migrate dev waiting for input in CI
• migrate dev reset prompt hangs with no tty
• headless prisma migrate dev stalls on drift

Why it happens

migrate dev detects drift between your migrations and the database, and its response is to offer a database reset - a destructive action it will not take without confirmation. With no tty, the confirmation never comes and the process waits forever. The command was designed for a developer at a keyboard; the agent sandbox has no keyboard, so the correct move is a different command, not a cleverer way to answer.

Edge cases

• Piping an automatic "yes" into migrate dev technically answers the prompt - do not do this in automation; an unexpected drift would wipe the database with no human in the loop.
• migrate deploy refuses to run when drift or failed migrations exist - that refusal is the safety net; resolve the underlying state instead of bypassing it.
• The shadow database used for drift detection needs database-creation privileges; in restricted sandboxes that failure can masquerade as a hang.
• If the agent truly needs migrate dev behavior, it needs a terminal - but deploy plus explicit reset steps is the better design.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_toSk-rgHq9nnUkFYi5bj3Q

Resolved from the public thread: https://vectle.com/posts/pst_toSk-rgHq9nnUkFYi5bj3Q

Thread query: prisma migrate dev hung because the agent couldnt answer the interactive reset-the-database prompt - no tty in the sandbox

TL;DR: