fix(prisma): make restore_todos_table migration idempotent #63

Merged

janpeter merged 1 commit from claude/suspicious-dirac-2e2511 into main 2026-06-01 16:16:52 +02:00

Conversation 0 Commits 1 Files changed 1 +28 -21

janpeter commented 2026-06-01 15:42:26 +02:00

Owner

Copy link

Summary

• Wraps prisma/migrations/20260506101436_restore_todos_table/migration.sql in a DO $$ ... EXCEPTION WHEN duplicate_table THEN NULL ... $$ block so it no-ops when todos already exists.
• Unblocks prisma migrate dev --create-only for any new migration; previous workaround was db execute + migrate resolve --applied (last hit in #62).

Why CREATE TABLE IF NOT EXISTS alone isn't enough

The init migration also creates the todos_user_id_done_archived_idx index and todos_user_id_fkey FK; add_todo_product_id adds the second index and FK. All four would conflict during shadow replay, not just CREATE TABLE. The DO block cleanly no-ops the whole migration when the table already exists.

Verification

Created a temporary scrum4me_shadow_test DB on the dev server, ran:

npx prisma migrate diff --from-empty --to-migrations prisma/migrations --script

Exit code 0; 1134 lines of replay SQL — every migration (including this one) replayed cleanly. Sequence in the shadow DB:

1. 20260424123750_init creates todos
2. 20260506101436_restore_todos_table (this fix) hits duplicate_table → handler catches → block exits → next migration runs
3. 20260507000000_migrate_todos_to_ideas later drops todos

Shadow DB dropped afterward; no test migration directory created.

Out of scope

Pre-existing drift on the dev DB (tables FlowRun/Session/FlowStep/User/WorkerEvent/WorkerRun, enums EventKind/FlowStatus/MetaTag/RunStatus, and 7 migrations applied to the DB but missing from prisma/migrations/ — including a second 20260513150226_init) — flagged separately, not addressed here.

Test plan

• Reviewer runs npx prisma migrate dev --create-only --name verify_fix against a clean shadow DB after this PR — should succeed without intervention.

## Summary - Wraps `prisma/migrations/20260506101436_restore_todos_table/migration.sql` in a `DO $$ ... EXCEPTION WHEN duplicate_table THEN NULL ... $$` block so it no-ops when `todos` already exists. - Unblocks `prisma migrate dev --create-only` for any new migration; previous workaround was `db execute + migrate resolve --applied` (last hit in #62). ## Why CREATE TABLE IF NOT EXISTS alone isn't enough The init migration also creates the `todos_user_id_done_archived_idx` index and `todos_user_id_fkey` FK; `add_todo_product_id` adds the second index and FK. All four would conflict during shadow replay, not just CREATE TABLE. The DO block cleanly no-ops the whole migration when the table already exists. ## Verification Created a temporary `scrum4me_shadow_test` DB on the dev server, ran: ``` npx prisma migrate diff --from-empty --to-migrations prisma/migrations --script ``` Exit code 0; 1134 lines of replay SQL — every migration (including this one) replayed cleanly. Sequence in the shadow DB: 1. `20260424123750_init` creates `todos` 2. `20260506101436_restore_todos_table` (this fix) hits `duplicate_table` → handler catches → block exits → next migration runs 3. `20260507000000_migrate_todos_to_ideas` later drops `todos` Shadow DB dropped afterward; no test migration directory created. ## Out of scope Pre-existing drift on the dev DB (tables `FlowRun`/`Session`/`FlowStep`/`User`/`WorkerEvent`/`WorkerRun`, enums `EventKind`/`FlowStatus`/`MetaTag`/`RunStatus`, and 7 migrations applied to the DB but missing from `prisma/migrations/` — including a second `20260513150226_init`) — flagged separately, not addressed here. ## Test plan - [ ] Reviewer runs `npx prisma migrate dev --create-only --name verify_fix` against a clean shadow DB after this PR — should succeed without intervention.

janpeter added 1 commit 2026-06-01 15:42:26 +02:00

fix(prisma): make restore_todos_table migration idempotent ... fb00d329b1

Wrap the migration body in a DO block with EXCEPTION WHEN duplicate_table
so shadow-DB replay no-ops when todos already exists from init +
add_todo_product_id + add_todo_description. On prod (after the out-of-band
drop) the CREATE TABLE still succeeds and the rest of the block runs.

Unblocks `prisma migrate dev --create-only` for any new migration; the
previous workaround was `db execute + migrate resolve --applied`.

Verified via `prisma migrate diff --from-empty --to-migrations` against a
temporary scrum4me_shadow_test DB — all migrations replay cleanly (exit 0).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

janpeter merged commit 555b290329 into main 2026-06-01 16:16:52 +02:00

janpeter referenced this pull request from a commit 2026-06-01 16:16:53 +02:00

Merge pull request 'fix(prisma): make restore_todos_table migration idempotent' (#63) from claude/suspicious-dirac-2e2511 into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

janpeter/Scrum4Me!63

No description provided.