From e0a7c68434234fa4d2309aad7ab629b44ad3b498 Mon Sep 17 00:00:00 2001 From: Guillermo Marin <52298929+guillermoscript@users.noreply.github.com> Date: Sun, 26 Jul 2026 04:13:29 +0200 Subject: [PATCH] fix(db): commit the #542/#543 ledger repairs so cloud has no orphan stamps (#541 follow-up) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cloud carried 175 migration stamps against 173 files on master. The two extra: 20260726013256 repair_migration_ledger_542 20260726015858 repair_migration_ledger_543 Both were applied through the MCP `apply_migration` tool while #542 and #543 were being worked, but neither committed a matching file. Each repair correctly realigned its own migration's stamp — and then became an orphan itself, because `apply_migration` stamps a FRESH timestamp rather than the filename. One orphan traded for another; the ledger never actually converged. Committing the files is what closes the loop, which is why #541's own repair shipped as 20260726005843_repair_migration_ledger_541.sql. The SQL in both files is reproduced verbatim from `supabase_migrations.schema_migrations.statements` for the corresponding version; only the explanatory headers were added. Nothing is re-applied to cloud — the statements have already run there, and this commit exists so the repo can account for them. Both are idempotent: on a fresh `supabase db reset` the UPDATEs match nothing, because the CLI stamps 20260726100000 / 20260726110000 from the filenames in the first place. Ledger after this commit: 175 files, 175 stamps, zero pending, zero orphans — verified by diffing supabase/migrations/ against schema_migrations. This is the condition `npm run verify:cloud` (#541) reports as "cloud carries no migration stamp that matches no repo file", and is how it was caught, hours after that check shipped. Gates: test:unit 411 passed, typecheck clean, build succeeds. Refs #540, #541, #542, #543 Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01HPFyHjqzSR6Ku1gyWjeQie --- ...0726013256_repair_migration_ledger_542.sql | 31 +++++++++++++++++++ ...0726015858_repair_migration_ledger_543.sql | 26 ++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100644 supabase/migrations/20260726013256_repair_migration_ledger_542.sql create mode 100644 supabase/migrations/20260726015858_repair_migration_ledger_543.sql diff --git a/supabase/migrations/20260726013256_repair_migration_ledger_542.sql b/supabase/migrations/20260726013256_repair_migration_ledger_542.sql new file mode 100644 index 00000000..5788b801 --- /dev/null +++ b/supabase/migrations/20260726013256_repair_migration_ledger_542.sql @@ -0,0 +1,31 @@ +-- Ledger repair for #542, reconstructed to close an orphan stamp (#541 follow-up). +-- +-- This SQL was applied to cloud on 2026-07-26 through the MCP `apply_migration` +-- tool while #542 was being worked, but no matching file was committed. The +-- statement below is reproduced verbatim from +-- `supabase_migrations.schema_migrations.statements` for version 20260726013256; +-- only this header has been added. +-- +-- WHY THE FILE HAS TO EXIST. `apply_migration` stamps a FRESH timestamp instead +-- of the migration's filename, so #542's repair correctly realigned +-- `rls_exam_child_tables_tenant_gate` — and then became an orphan stamp itself, +-- because the repair carried a stamp (20260726013256) that matched no file in +-- supabase/migrations/. Net effect: one orphan traded for another. Committing +-- the file is what actually closes the loop, and is why #541's own repair +-- shipped as 20260726005843_repair_migration_ledger_541.sql. +-- +-- `npm run verify:cloud` reports exactly this condition ("cloud carries no +-- migration stamp that matches no repo file"), which is how it was caught. +-- +-- Idempotent: on a fresh `supabase db reset` the UPDATE matches nothing, because +-- the CLI stamps 20260726100000 from the filename in the first place. It is a +-- no-op everywhere except the cloud project it has already run on. + +-- The MCP apply_migration stamps a fresh timestamp rather than the repo +-- filename's, which makes the repo migration look absent from cloud to any +-- drift check that compares versions (#541). Realign this one row with +-- supabase/migrations/20260726100000_rls_exam_child_tables_tenant_gate.sql. +UPDATE supabase_migrations.schema_migrations + SET version = '20260726100000' + WHERE name = 'rls_exam_child_tables_tenant_gate' + AND version = '20260726013216'; diff --git a/supabase/migrations/20260726015858_repair_migration_ledger_543.sql b/supabase/migrations/20260726015858_repair_migration_ledger_543.sql new file mode 100644 index 00000000..21bcf6a5 --- /dev/null +++ b/supabase/migrations/20260726015858_repair_migration_ledger_543.sql @@ -0,0 +1,26 @@ +-- Ledger repair for #543, reconstructed to close an orphan stamp (#541 follow-up). +-- +-- This SQL was applied to cloud on 2026-07-26 through the MCP `apply_migration` +-- tool while #543 was being worked, but no matching file was committed. The +-- statement below is reproduced verbatim from +-- `supabase_migrations.schema_migrations.statements` for version 20260726015858; +-- only this header has been added. +-- +-- Same shape as its sibling 20260726013256_repair_migration_ledger_542.sql: +-- `apply_migration` stamps a FRESH timestamp instead of the migration's +-- filename, so #543's repair correctly realigned `write_side_entitlement_gates` +-- and then became an orphan stamp itself (20260726015858 matched no file). +-- Committing the file is what closes the loop. +-- +-- Idempotent: on a fresh `supabase db reset` the UPDATE matches nothing, because +-- the CLI stamps 20260726110000 from the filename in the first place. It is a +-- no-op everywhere except the cloud project it has already run on. + +-- Ledger repair for #543. `apply_migration` stamps a fresh timestamp rather than +-- the repo filename (see #541), so 20260726110000_write_side_entitlement_gates.sql +-- landed as version 20260726015553. Realign the version with the file so +-- repo-vs-ledger diffing stops reporting it as pending. +UPDATE supabase_migrations.schema_migrations +SET version = '20260726110000' +WHERE name = 'write_side_entitlement_gates' + AND version = '20260726015553';