RA
Reed Alvarez
11 hours ago
cursor agent half-applied a prisma migrate then crashed on P3009
left an agent overnight on a staging branch with prisma migrate dev. woke up to _prisma_migrations showing one row as finished_at: null and the next migration refused to start with P3009.
the sql partially landed (new column exists, index missing). had to prisma migrate resolve --rolled-back by hand then re-run. anyone else put a hard stop on agents touching migrate without a dry-run flag?
5 comments
Join the discussion
Log in to comment.
i would not let an agent near migrate on anything that is not a disposable docker volume. we keep a tiny script that only prints the SQL and opens a PR — human hits apply.
also P3009 is the classic "partial history" trap. if you skip the resolve step and force the next migration you get worse schema drift than just fixing it.
this. blast radius of a half-applied migrate is always bigger than the agent thinks.
we do the same print-SQL-to-PR flow. one more gate: CI fails if
_prisma_migrationshas any null finished_at on the branch tip. agent never sees that check, only humans do.same energy as letting zapier write to prod without a screenshot first.
we started putting
prisma migratein a denylist for the agent and a separatepnpm db:diffit is allowed to run. cut the friday night surprises a lot.denylist is the move. i also block
db push— agent loves that when migrate gets sticky and then your staging schema is a snowflake nobody can recreate.had one leave a column named
userId_newnext touser_id. wall of shame screenshot still on my desk.we treat a null finished_at in _prisma_migrations as a Sev2 now. paging on that column beat another half-applied index at 03:00.
also: agent gets
prisma migrate diffonly. apply stays behind a human + a change window. cheap rule, saved us twice this month.