From 7fea46790ad904141264203951b5536192f0c865 Mon Sep 17 00:00:00 2001 From: Anthony Ettinger Date: Sat, 15 Aug 2026 21:06:13 +0000 Subject: [PATCH] chore(db): align the drop migration filename with the applied prod version Applied to prod after #250 deployed; the MCP restamped it as 20260815210532. Rename so supabase db push does not rerun it, and record that it is already applied. --- ...0815204334_move_backup_pins_to_service_role_table.sql | 2 +- ...sql => 20260815210532_drop_users_backup_pin_hash.sql} | 9 +++++---- 2 files changed, 6 insertions(+), 5 deletions(-) rename supabase/migrations/{20260815204400_drop_users_backup_pin_hash.sql => 20260815210532_drop_users_backup_pin_hash.sql} (77%) diff --git a/supabase/migrations/20260815204334_move_backup_pins_to_service_role_table.sql b/supabase/migrations/20260815204334_move_backup_pins_to_service_role_table.sql index 97bb5de..eacd75d 100644 --- a/supabase/migrations/20260815204334_move_backup_pins_to_service_role_table.sql +++ b/supabase/migrations/20260815204334_move_backup_pins_to_service_role_table.sql @@ -67,7 +67,7 @@ ON CONFLICT (user_id) DO NOTHING; -- -------------------------------------------------------------------------- -- The `users.backup_pin_hash` column itself is dropped by the NEXT migration, --- 20260815204400_drop_users_backup_pin_hash.sql. It is deliberately a separate +-- 20260815210532_drop_users_backup_pin_hash.sql. It is deliberately a separate -- step: this migration is additive and safe to apply to a running deployment, -- whereas the drop must not land until the application code that stopped -- reading that column has shipped. diff --git a/supabase/migrations/20260815204400_drop_users_backup_pin_hash.sql b/supabase/migrations/20260815210532_drop_users_backup_pin_hash.sql similarity index 77% rename from supabase/migrations/20260815204400_drop_users_backup_pin_hash.sql rename to supabase/migrations/20260815210532_drop_users_backup_pin_hash.sql index 6ca6d5a..450a863 100644 --- a/supabase/migrations/20260815204400_drop_users_backup_pin_hash.sql +++ b/supabase/migrations/20260815210532_drop_users_backup_pin_hash.sql @@ -2,10 +2,6 @@ -- Advisory: GHSA-jpfm-vrpc-p6rr -- -- Second half of 20260815204334_move_backup_pins_to_service_role_table.sql. --- --- NOTE: when this is applied via the Supabase MCP, the ledger will restamp it --- with its own timestamp. Rename this file to match afterwards, or --- `supabase db push` will rerun it. -- That migration created the service-role-only `user_backup_pins` table and -- carried across which users have a PIN set. This one removes the column that -- every logged-in account could read via `users_select_authenticated`. @@ -14,6 +10,11 @@ -- `users.backup_pin_hash` is deployed (src/app/api/auth/backup-pin/route.js). -- Applying it against the previous release breaks GET/POST /api/auth/backup-pin. -- +-- APPLIED TO PRODUCTION 2026-08-15, after #250 deployed. The ledger restamped it +-- as version 20260815210532 (the Supabase MCP ignores the filename timestamp and +-- records its own), and this file was renamed to match so that +-- `supabase db push` does not rerun it. +-- -- The unsalted SHA-256 digests in this column are discarded rather than -- migrated: nothing ever verified them server-side, they only backed a boolean, -- and their whole problem is that they are trivially reversible.