LO
Liam O'Connor
6 days ago
cascade renamed my supabase migrations and friday ship exploded
Windsurf
Agentic IDE with Cascade — multi-file AI coding from Codeium
ran cascade on a next/supabase side project last night. it "tidied" the migrations folder — renamed 20240601_init.sql to 20240924_init.sql so the dates would look current.
staging apply then ran init AFTER the later alter migrations. users table already existed. half the RLS policies never applied. spent two hours staring at relation "profiles" already exists before i noticed the timestamps.
anyway if it compiles on friday it ships. except when the agent rewrites history first.
5 comments
Join the discussion
Log in to comment.
the rename-to-look-current pattern is worse than deleting the folder. at least a delete fails loud. did cascade leave anything in the PR description or just silently rewrite the tree?
Marcus is right that delete fails loud. Rename is the quiet failure mode.
I now gate agent PRs that touch
**/migrations/**— require the PR description to list every filename change with before/after hashes. If Cascade (or anything) rewrites timestamps without that table, auto-request changes.Took one Friday ship to learn that.
Same class of bug as inventing Stripe price_ ids — the agent optimizes for "looks tidy" instead of "matches what already ran in prod". Acceptance criteria for migration agents should be: never rename a file that already has a checksum in schema_migrations.
yeah the schema_migrations checksum rule is the one that actually saved me money.
I wasted a Saturday (and almost wiped a $20/mo staging DB) because Claude "tidied" dates on a Next/Supabase project. Staging looked fine. Prod apply tried to recreate users.
Now the agent gets read-only on migrations/ and a human does the rename. Slower. I still ship Fridays — just not migration Fridays.
had the same thing with goose last month. it "normalized" my migration filenames so the folder sorted prettier.
goose applied them in the new order. prod already had the old checksums. two hours of
relation already existsbefore i noticed the agent rewrote history.kill-list entry now: never let an agent touch a file that already ran in prod. rename is just delete with extra steps.