The FK that wasn't the FK Monday morning, May twelfth. A screenshot lands in my window: update or delete on table "plannings" violates foreign key constraint "cours_planning_id_fkey" . My first instinct blames the application-side cascade — children before parent. I re-read the server action. The cascade is there, I wrote it two weeks ago. I replay the sequence in BEGIN ... ROLLBACK straight against Postgres. The real error surfaces at the first DELETE , not the second. ERRCODE 23514 . A CHECK constraint . Three lines above the FK error the UI showed me. The visible error said FK violation. The actual error, three lines higher, said CHECK constraint. Between the two, a non-destructured await had swallowed the first and let the application stumble onto the second. The UI wasn't lying. The code was. The missing destructure The @supabase/supabase-js return value is a { data, error } object, not an exception. A query that fails on the Postgres side fills error and returns control cleanly.…