Skip to main content

Fix a Flaky DB Migration Playbook

Your db-migration playbook works on simple schemas but blows up on foreign keys. Feed four session links into Advanced Devin and let it patch the gaps.
AuthorCognition
CategoryDevin Optimization
FeaturesAdvanced, Playbooks
1

Spot the pattern across sessions

Your team has been using the !db-migration playbook for a few weeks. It handled renaming columns and adding indexes without issue — but the last two sessions crashed mid-migration when they tried to drop a column referenced by other tables.Open each session and look at the failure point. In this case, sessions 3 and 4 both errored at the same step:
ERROR: cannot drop column "account_id" because other objects depend on it
DETAIL: constraint fk_orders_account_id on table orders depends on column account_id
HINT: Use DROP ... CASCADE to drop dependent objects too.
You now have a clear signal: the playbook has no step for checking foreign key dependencies before destructive operations. Two sessions succeeded because they touched standalone tables; two failed because they didn’t.
2

Open the Improve Playbook tab with session links

Go to app.devin.ai and click Advanced below the input box. Select the Improve Playbook tab.Pick !db-migration from the playbook dropdown, then select all four sessions from the session multi-dropdown — both the successes and the failures. Including successful sessions lets Devin see what the playbook does well, not just where it breaks.What makes this prompt effective:
  • Names the exact failure — “foreign key constraints” instead of “it sometimes fails”
  • Contrasts successes and failures — Devin can diff the session transcripts to see where they diverge
  • Lists concrete fixes while leaving room for Devin to surface issues you missed
3

Review the playbook diff

Devin reads all four session transcripts, pinpoints where failures diverged from successes, and proposes targeted edits. The output looks like a changelog for your playbook:
## Analysis

Sessions 1-2 succeeded because they only modified tables with no
incoming foreign keys. Sessions 3-4 failed at step 4 ("Drop the
old column") because the orders and invoices tables had FK
references to the target column.

## Changes to !db-migration

Added step 3a: "Before any DROP or ALTER that removes a column,
  query information_schema.key_column_usage to list dependent FKs.
  If any exist, generate ALTER TABLE ... DROP CONSTRAINT statements
  and execute them first. Save the original constraint DDL for
  rollback."

Added step 7: "Rollback procedure — if any step after FK removal
  fails, re-create the dropped constraints using the saved DDL
  from step 3a."

Updated Advice section: "Always run the migration against a staging
  database first. FK chains can be deeper than expected — a column
  in table A may be referenced by B, which is referenced by C.
  Query recursively."
The playbook saves automatically. If something is off, reply in the same session — for example, “Also add a step to notify the #database Slack channel before running destructive migrations.”
4

Verify the fix on a fresh migration

You don’t need to leave your current Advanced Devin session. After the playbook update is saved, use the same session to launch a standard Devin session that tests the updated playbook against the exact scenario that failed before:If this session succeeds, the fix works. If it hits a new edge case (e.g., circular FK references), feed that session back into the Improve Playbook tab for another round.