the agent's prisma migrate lost its database connection halfway - the _prisma_migrations table has a row stuck in...

TL;DR: Inspect the failed row, decide whether the migration actually landed, then tell prisma which it is with migrate resolve. If the schema changes are present in the database, mark the migration applied; if not, mark it rolled back and re-run the deploy. Never delete the row by hand - resolve is the supported path and keeps prisma's bookkeeping consistent.

The problem as reported:

the agent's prisma migrate lost its database connection halfway - the _prisma_migrations table has a row stuck in failed state

1. Look at the stuck row: select migration_name, started_at, finished_at, applied_steps_count from _prisma_migrations where finished_at is null;. Expected: one row for the interrupted migration, with finished_at null.
2. Check whether its changes actually landed: compare the live schema against the migration's SQL file (inspect the affected tables in psql and read the migration.sql). Expected: a yes-or-no answer - the statements either ran or they didn't.
3. If the changes ARE in the database: npx prisma migrate resolve --applied "MIGRATION_NAME" (copy the exact name from step 1). Expected: prisma reports the migration marked as applied.
4. If the changes are NOT there: npx prisma migrate resolve --rolled-back "MIGRATION_NAME", then npx prisma migrate deploy. Expected: the failed row is cleared and the migration applies cleanly.
5. Run npx prisma migrate status. Expected: "Database schema is up to date" with no failed migrations listed.

Use this when

• A prisma migrate died mid-run after losing its database connection.
• prismamigrations has a row with finished_at null blocking later deploys.
• You need to choose between resolve --applied and --rolled-back.

Not for this skill when

• The complaint is drift rather than a failed row - that's a baseline problem, different fix.
• You're on migrate dev fighting the shadow database - that's a shadow-DB issue, not a failed production migration.

Variant phrasings

• prisma migration stuck in failed state
• prisma migrate resolve applied vs rolled back
• prismamigrations finished_at null
• prisma deploy blocked by failed migration

Why it happens

Prisma writes the migration row when the migration starts and only stamps finished_at on success. A dropped connection leaves the row open, and every later deploy refuses to proceed until that row is explicitly resolved.

Edge cases

• The migration half-applied (some statements ran): reconcile the schema by hand before resolving - resolving --applied on a half-applied migration corrupts future diffs.
• MIGRATION_NAME must match exactly: copy it from the step-1 query; a typo resolves nothing.
• Resolving --applied when the migration did NOT land: prisma will believe the schema changed and generate wrong diffs forever after - when in doubt, roll back and re-run.

Provenance

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