feat(db): Phase 3 staging proof + forward-codify three hybrid RPC bodies the chain never received (#316) - #2111
Conversation
… bodies the chain never received (#316) Staging (ikoiolksxqxfxgiyqpnu, owner-authorised window) received 20260818110000/111000/112000 by the Phase 2 method with md5-identical history rows. Offline reproduction of check:drift shows the eight never-created objects, the three column-set mismatches and four of the seven work_mem mismatches gone; residual: the expected trgm index plus three functions whose bodies still carry the legacy fail-open owner predicate on a chain-built database (embedding_fields_hybrid, index_units_hybrid, memory_cards_hybrid_v2) — never forward-codified after 20260712000000. schema.sql == production for all three (manifest hash = live hash), so this is a reproducibility hole, not a production tenancy hole. - 20260818113000_forward_codify_hybrid_owner_matches_bodies: the three definitions verbatim from schema.sql (all SET clauses restated); no-op on production. Its staging apply is pending owner permission. - forensics section 3.5 rewritten with the staging evidence; 3.6 window table now lists five migrations. - #316: earlier update request cancelled (same-id collision) and replaced by one combined update carrying the staging result. RAG impact: no retrieval behaviour change - codifying already-live SET work_mem attributes, mirror-only objects, and three already-live bodies; no canonical function body changed Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:35 minutes Limit details: You’ve used all 1 included review currently available under your plan. You completed 101 included PR reviews in the past 7 days; at that activity level, included reviews refill at 1 review per hour. 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 (8)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
…w-up) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Updates to Preview Branch (claude/db-phase3-staging-proof-bodies) ↗︎
Tasks are run on every commit but only new migration files are pushed.
View logs for this Workflow Run ↗︎. |
…ws refreshed, single trgm residual (#316) Second owner-authorised staging window on ikoiolksxqxfxgiyqpnu: applied 20260818113000 (three hashes now equal manifest/live), refreshed the 111000/112000 history-row text to the merged files, all four rows md5 = repo; final offline drift comparison = UNEXPECTED DRIFT (1), document_chunks_content_trgm_idx only. #316 request superseded by one final update. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…plete) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Uh oh!
There was an error while loading. Please reload this page.
One of the two pending #316 requests (10e480da) already had a cancel from the original batch (8b0650ed, 'superseded within PR #2111'). Cancelled the other stale one (22946f19, whose baseRowFingerprint no longer matched the current row) and reissued its content -- the more complete of the two, describing the finished two-window staging proof -- as a fresh update request against the row's current content.
Summary
Follow-up to #2106 (database remediation Phase 3, ledger
#316): the staging proof that #2106's gate opened for once the Phase 2 re-measure (#2104) merged, plus the one migration it turned out to need. No canonical (schema.sql = production) function body changed; no hosted value changed; no production access.RAG impact: no retrieval behaviour change — codifying three already-live RPC bodies into the migration chain, byte-for-byte from schema.sql; no canonical function body changed
Clinical KB Staging(ikoiolksxqxfxgiyqpnu; ref verified vialist_projects, project id passed literally on every call; production never targeted).20260818110000/111000/112000applied by the Phase 2 method (file verbatim + explicitschema_migrationsrow, neverapply_migration); md5-identical read-back for all three at apply time; staging 198 rows,no_statements 0, corpus 0. Offline reproduction ofcheck:drift(samecategoryKeys/comparedFields, per-object md5 on staging vs. the manifest rendered in jsonb text form; 590/594 objects hash-equal, which validates the method): the 8 never-created objects, the 3 column-set mismatches and 4 of the 7work_memmismatches are gone. Residual 4:document_chunks_content_trgm_idx(the expected Phase 4.4 residual) and three functions whose ACL andproconfignow equal the manifest but whose bodies differ.20260818113000_forward_codify_hybrid_owner_matches_bodies.sql— the reason for those three. On a chain-built databasematch_document_embedding_fields_hybrid,match_document_index_units_hybridandmatch_document_memory_cards_hybrid_v2still carry the legacy fail-open, sentinel-blind predicate(owner_filter is null or d.owner_id = owner_filter):20260712000000_forward_codify_retrieval_owner_matches.sqlleft the body codification to an owner step, five other RPCs were codified later, these three never were (newest chain body20260701140631).schema.sql== production for all three (manifestdef_hash= livedef_hash, forensics §3.1), so this is a reproducibility hole for migrations-only environments, not a production tenancy hole. The migration re-creates the three verbatim fromschema.sqlwith everySETclause restated (proconfig preserved; ACLs untouched byCREATE OR REPLACE); no-op on production. Protected RAG surface: this migration contains RPC bodies — copied byte-for-byte from the canonical definitions, nothing edited.Applied to staging in a second owner-authorised window: the three hashes now equal manifest and live (bb975485…,d0e277a2…,ab87a18b…), history rowmd5 d35c199b… = repo.UNEXPECTED DRIFT (1)=document_chunks_content_trgm_idxonly — zero function mismatches, zero never-created objects, zero table mismatches (the Phase 3 target); the single residual is the Phase 4.4 trgm rebuild.20260818111000/112000gained aset local lock_timeout / statement_timeoutpreamble, so the text onmain(22585b9e…,ec154770…) differed from what staging had recorded (9d02d14e…,ea5f9c69…; identical DDL). The two staging rows were refreshed to the merged text in the second window; all four rows now read back md5 = repo (forensics §3.5).#316update requests (4dbcdcce…onmain,10e480da…on this branch) are cancelled in-inbox and replaced by one final update carrying the completed staging result (two updates on one id would blockissues:reconcile).Production window — NOT authorised in this PR (for the coordinator)
20260818090000_schema_drift_snapshot_history_probeschema_drift_snapshot()v2 (Phase 6.1)20260818110000_codify_live_rpc_work_memwork_memvalues already match20260818111000_codify_schema_only_indexes_and_triggers20260818112000_reconcile_chain_stale_table_columns20260818113000_forward_codify_hybrid_owner_matches_bodiesOne window, no canary (D2), no index build, no body that production does not already run.
Verification
npx vitest run tests/supabase-schema.test.ts tests/migration-history-guards.test.ts tests/search-health-index-coverage.test.ts tests/hosted-migration-role-guard.test.ts tests/migration-history-placeholders.test.ts tests/drift-detection.test.ts—Test Files 6 passed (6) · Tests 109 passed (109)npm run check:migration-role—Hosted migration-role guard passed: active hosted SQL/tooling uses postgres and immutable applied history is unchanged.npm run check:outstanding-issues—Outstanding-issues guard passed: 361 rows (105 open, 256 archived) …;npm run docs:check-links—docs link check passed: 1921 repo path references resolve.npm run verify:pr-localnot re-run in full for this follow-up: the diff is one migration file (bodies verbatim from the unchangedschema.sql, sodrift-manifest.jsonis unchanged and its freshness test passes), a forensics section, and two inbox JSON files; the full gate ran green on feat(db): codify live SET work_mem on the ten match_* RPCs, the eight schema-only objects, and three chain-stale columns (#316) #2106 (lint,typecheck, full unit suite except the known Windows-environmental/host-load failures) and nothing here touches lint/typecheck surfaces.eval:retrieval:qualitynot run: no retrieval, ranking, selection, chunking, or scoring behaviour changed (bodies identical to production; owner decision D2 for the surrounding work).Risk and rollout
ikoiolksxqxfxgiyqpnu) received20260818110000/111000/112000/113000in two owner-authorised windows (plus the two history-row text refreshes); production untouched.Clinical Governance Preflight
Complete this section when the change touches ingestion, answer generation, search/ranking, source rendering, document access, privacy, production env, or clinical output.
Clinical KB Database(sjrfecxgysukkwxsowpy)Notes
match_*bodies, copied verbatim fromschema.sql; the equality of manifest and live hashes for those three is the proof they are production's bodies.claude/schema-work-mem-codify-6200f1was deleted (owner-authorised).