docs(audit): fill Phase 1.2 and extend 1.3 with whole-schema drift evidence - #1970
Conversation
…idence Read-only connector session, additive to the same day's incident window. 1.2 (was Pending) — all 93 public functions compared by the manifest's own hash rule: 0 missing, 0 extra, 16 mismatches, all match_document_*. Six are proven normalization noise: re-qualifying vector -> extensions.vector reproduces the manifest hash exactly, so those bodies are byte-identical. The other ten are real and recorded UNCLASSIFIED per the section's own rule, pending decisive hunks. This independently confirms #316's figure of 10. Also records the join trap: comparing manifest signatures to live regprocedure directly reports all 93 as simultaneously missing and extra, because the manifest stores public.fn(extensions.vector,...) and a live session renders fn(vector,...). That is a join failure, not a finding. 1.3 — whole-schema inventory after the incident repair, explicitly additive rather than a restatement: 210 repo-defined vs 192 live, 20 still absent, 2 orphaned (210-20+2=192). Both repaired indexes confirmed present. Zero invalid-or-not-ready indexes, so the failed-CREATE-INDEX-CONCURRENTLY class explains none of them. All five creating migrations recorded executed DDL (stmt_count 32/36/14/27/11, none mark-applied), generalising 1.1's conclusion beyond one migration. Root cause is explicitly left unestablished; the dashboard audit-history pairing remains the owner action that would settle attribution. Ledger: #316 and #248 queued as inbox requests carrying the same evidence. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017paT42ZVMf8jaLtkjFxdy5
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:28 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
Comment |
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017paT42ZVMf8jaLtkjFxdy5
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:00f5612ccf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
CI triageCI failed on this PR. Automated classification of the 2 failed job(s):
Compared with main CI run #10953 (success). Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger. |
Summary
Read-only Supabase connector session, additive to the same day's owner-authorized incident window — this does not restate or revise the incident work, and both indexes repaired there are confirmed still present on live.
docs/audit— §1.2 RPC divergence dossier was_Pending._and is now enumerated. All 93publicfunctions compared by the manifest's own hash rule (pg_get_functiondef, comments and whitespace stripped, md5) againstsupabase/drift-manifest.json: 0 missing on live, 0 extra, 16 hash mismatches, every one amatch_document_*retrieval RPC.vector); the manifest was generated where they renderextensions.vector. Re-qualifying before hashing reproduces the manifest hash exactly — e.g.match_document_chunks→cdf9d685c98bc8ff731a0422c29a47a4. Those bodies are byte-identical to the repo.UNCLASSIFIED, per that section's own rule — they match under no variant, so the difference is in the body, but deciding live-ahead vs repo-ahead needs the decisive hunk and this is a protected RAG surface. This independently confirms#316's figure of 10.docs/audit— §1.3 extended with a whole-schema inventory. 210 repo-defined indexes vs 192 live: 20 still absent, 2 orphaned on live. 210 − 20 + 2 = 192, so neither side is a partial read.public, so the failed-CREATE INDEX CONCURRENTLYclass documented indocs/database-drift-detection.mdexplains none of the 20. The objects are absent, not broken.stmt_count32 / 36 / 14 / 27 / 11, none carrying the mark-applied signal, including20260712165211_reconcile_missing_operational_indexes. This generalises §1.1's conclusion beyond one migration and beyond the two repaired indexes.#316and#248queued as inbox requests carrying the same evidence, appended to their existing detail rather than replacing it. Apply withnpm run issues:reconcile.Root cause is explicitly left unestablished. §1.1's manual/dashboard-drop inference remains the leading hypothesis and the dashboard audit-history pairing is still the owner action that would confirm or refute it. This inventory widens what that pairing has to explain; it attributes nothing on its own.
One arithmetic discrepancy recorded rather than smoothed over:
#316says 21 missing and 2 were restored, which would leave 19 — I measure 20. The row now carries 20 as the measured current figure and flags 21 as approximate.A method trap is recorded in §1.2 so the next run doesn't repeat it. Joining manifest signatures directly to live
p.oid::regprocedure::textreports all 93 functions as simultaneously missing and extra, because the manifest storespublic.fn(extensions.vector,…)while a live session rendersfn(vector,…). That is a join failure, not a finding. I hit it on the first pass; normalize both sides, then test each surviving mismatch against the qualification variants before calling it divergence.Verification
npm run verify:pr-localEvery figure was measured read-only against
sjrfecxgysukkwxsowpyviapg_indexes,pg_index,pg_procandsupabase_migrations.schema_migrations, compared against the committedsupabase/drift-manifest.json. No writes were performed and no migration was applied.UI verification not run: no UI, routing, styling, or browser-behaviour change in this diff.
Risk and rollout
git revertthe single commit.Clinical Governance Preflight
Not applicable as a checklist:
classifyPullRequestFilesreturnsclinicalRisk: false,operationalRisk: false,ragRanking: false,ui: falsefordocs/audit/**anddocs/outstanding-issues-inbox/**. The diff changes no ingestion, answer-generation, ranking, source-rendering, document-access or privacy code — it records read-only measurements about the live database. The RAG-surface implications it documents are precisely what the follow-on window must gate, and this PR deliberately performs none of that work.Generated by Claude Code