Catalog census of Pluto migration effects absent from production

Sub-tickets

Activity

• coder-pluto-cc created · 1w ago
• db-pluto-ca assigned · 1w ago
  db-pluto-ca / db
• db-pluto-ca blocked · 1w ago
  Census needs SELECT on supabase_migrations.schema_migrations. This session's direct DSN is coder_pluto_cc_ro and gets permission denied for the schema; Supabase MCP execute_sql and list_migrations both deny permission. Local applied files 001-131: 129. Awaiting a postgres-authorized read route; no ledger write attempted.
• db-pluto-ca unblocked · 1w ago
  PM directed read-only catalog-first audit of all 129 applied migration files; registry access is no longer the first gate. Report absent effects with method limits before any remedy.
• pmmaster-evolutiva-cc note · 1w ago
  Registry read is a measured dead end, not a routing problem: coder_pluto_cc_ro and support_evolutiva_cc_ro BOTH get permission denied for schema supabase_migrations, and Supabase MCP list_migrations/execute_sql deny as well. Do not route this to another seat. Answer the real question with the access the lane already holds - for each of the 129 files assert the objects it creates or alters exist in the catalog, and report the files whose effects are ABSENT. An applied migration leaves its objects behind; a registry row would add nothing a catalog read cannot settle. Name what the method cannot see: a file applied then reverted by a later one, and a file whose effects are indistinguishable from another's.
• pmmaster-evolutiva-cc note · 1w ago
  Registry read is a measured dead end, not a routing problem: coder_pluto_cc_ro and support_evolutiva_cc_ro BOTH get permission denied for schema supabase_migrations, and Supabase MCP list_migrations/execute_sql deny as well. Do not route this to another seat. Answer the real question with the access the lane already holds - for each of the 129 files assert the objects it creates or alters exist in the catalog, and report the files whose effects are ABSENT. An applied migration leaves its objects behind. Name what the method cannot see: a file applied then reverted by a later one, and a file whose effects are indistinguishable from another's.
• support-evolutiva-cc note · 1w ago
  support-evolutiva-cc probe, own named role support_evolutiva_cc_ro (PLUTO_RO_DSN): SELECT version, name FROM supabase_migrations.schema_migrations ORDER BY version -> ERROR: permission denied for schema supabase_migrations. Same refusal as coder_pluto_cc_ro, so routing an already-authorized reader is a measured dead end, not an open action. The catalog method is the only path from here.
• db-pluto-ca progress · 1w ago
  Read-only catalog audit of 129 applied files (001-131; absent filename numbers 042,110): zero absent current effects found in 473 final object/column/constraint/index/trigger checks across 111 files; 55 latest function bodies matched source after comment/whitespace normalization. Manual reads: 30/30 search_path pins, 5/5 ALWAYS guards, exact data-fix archive counts for 038 (7+1+6) and 039 (6), 052/075/129 seed evidence, 022/047/074/100/120 catalog effects. cron.job denied to coder_pluto_cc_ro; cron effects in 008/025/026/030/033/035/049/087 unverified. Earlier effects overwritten by later migrations cannot be proven from current catalog alone. Migration 131's effects are present but its missing registry row remains a separate replay risk. No ledger write or remedy proposed; PM informed on original thread.
• db-pluto-ca completed · 1w ago
  Coverage: 129 applied SQL files numbered 001-131 (no files 042 or 110). Read-only production audit found 0 absent current effects across 473 final catalog checks of relations, columns/types, named constraints, indexes/targets/uniqueness, functions and triggers in 111 files; 55 latest function bodies matched normalized source. Manual checks covered archive/data-only row evidence, 30 search_path pins, 5 ALWAYS triggers, role/ACL/timeout/not-null effects. Not settled by this method: (1) cron job registration/schedule: coder_pluto_cc_ro is denied cron.job. At the last 03:17 and 04:20 UTC prune ticks there were zero eligible rows, so delete-only jobs left no attributable success event; net._http_response has two 200 drain-endpoint-shaped responses at 2026-10-06 10:15:51 UTC, but no retained request-to-job binding; unscheduled jobs emit nothing by design. Named cron.job read needed only for those still ambiguous. (2) Earlier function/view definitions overwritten by later migrations can never prove their own historical application from today's catalog. The separate registry-driven rebuild gap is PLUTO-779; no ledger remedy was chosen here.
• db-pluto-ca titleChanged · 1w ago
  Catalog census of Pluto migration effects absent from production
• db-pluto-ca descriptionChanged · 1w ago
  was: Spun out of PLUTO-437 R4. ESTABLISHED FACT, two reads from two seats: db-pluto-cc read supabase_migrations.schema_migrations as postgres on the direct DSN and there is NO row for 131 - latest is 130, applied via apply_migration. coder-pluto-cc could not read that schema at all (permission denied for coder_pluto_cc_ro) and so could only say absent-or-unreadable; it is the TWO reads together that make it a fact rather than a suspicion, and neither seat alone could have produced it. THE GAP: migration 131 was applied by raw psql rather than apply_migration. The DATABASE is correct - the readback confirmed both tables, all grants, RLS and the trigger. The LEDGER is wrong. So a rebuild driven from the registry reconstructs a schema with 131 missing entirely, and nothing in the tree records which migrations are affected. PLUTO-437 is NOT defective for this; the DDL is right and the readback passed. WHY IT IS WORSE THAN ONE MISSING ROW: the exposure belongs to every lane that has ever applied by psql instead of apply_migration, and the registry is precisely the artifact a disaster rebuild would trust. A ledger that is silently incomplete is worse than an absent one, because a replay from it succeeds and produces a subtly wrong schema rather than failing loudly. SCOPE BEFORE REMEDY, per pmmaster: count how many applied migrations have no registry row. Local half, measured 2026-10-06: 129 files in db/migrations/applied/, spanning 001-vAppErrorsRecent-views.sql to 131-pluto-437-pacientes-identity-anchor.sql. The other half needs a read of supabase_migrations.schema_migrations, which requires postgres - coder_pluto_cc_ro is denied, so this row sits with db-pluto-cc. Do NOT assume the answer is one: 129 files against a registry whose latest entry is 130 says nothing about how many of the other 128 were psql-applied. Deliverable for this row is the NUMBER and the list first, then a decision on the remedy. Backfilling rows is one option and is itself a write to a ledger, so it is not obviously the right one - a recorded manifest of psql-applied migrations may be the honest artifact instead. Decide after the count, not before. RELATED STANDING RISK worth naming on this row: the same disaster-rebuild path also reads db/schema.md, which PLUTO-772 just proved had been missing every primary key, foreign key, unique constraint and trigger since 2026-10-04. Both of the artifacts a rebuild would lean on were degraded at the same time, independently and for unrelated reasons.