docs(issues): reconcile 19 queued ledger requests and close #316 - #2261
Conversation
…ledger Applies the requests queued since #2229's reconcile, including the six raised by the Phase 5 close-out (#2250). Two carried explicit cancellation decisions. Net effect on the queue: - `#316` (live drift: 20 missing indexes, 10 divergent RPC bodies, weekly live-drift red since 2026-07-26) is CLOSED. Both original halves closed earlier; the last follow-on, Phase 5 measurement, completed 2026-08-22, and the alarm was observed clear on live-drift run 32514326022. - `#231` updated: plan §5.2 confirmed satisfied with fresh data, and the stale A1 recommended-queue framing corrected to match its own P2 re-grade. - Three new findings recorded: the uncapped Supabase Branching Compute cost; the missing EXPLAIN baseline for the `document_index_units` path plus the absent query-specific plan-flip evidence; and the observation that all 22 restored indexes report zero scans, which makes ANALYZE rather than the trigram restore the better-supported explanation for the incident recovery. Run from a fresh base off origin/main, as the serialized reconcile contract requires. Do not merge main into this branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:27 minutes Limit details: You’ve used the included review currently available. Your 89 included PR review attempts over the past 7 days set your current allowance 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?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day 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 (20)
Comment |
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:a2ee66c6ec
ℹ️ 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".
| | #102 | P3 | task | Apply the additive `documents` index debt (operator) | UPDATE 2026-08-21 (read-only Supabase MCP get_advisors performance lint against production ref sjrfecxgysukkwxsowpy): documents_title_trgm_idx exists on public.documents and is reported by the unused_index lint as never used. TREAT THAT AS WEAK EVIDENCE, NOT CONFIRMATION: 20260819100200_restore_search_health_trigram_indexes was applied two days earlier and recreating an index resets its usage statistics, so a zero-use reading is expected regardless of whether the bare-column ILIKE predicates can reach it. The same lint currently reports 31 unused indexes, several of them freshly restored in the 20260819100000-100300 batch, which is consistent with a stats reset rather than dead indexing. The row's actual claim - that the index covers a CONCATENATED expression and so cannot serve the bare-column predicates in the documents API route and rag-candidate-sources - was NOT tested, because that needs EXPLAIN or a pg_indexes read and SQL execution was blocked in this session. Re-measure with EXPLAIN in the operator window before applying the prepared runbook. | `docs/audit/latency-audit-2026-07-28.md` L2-3/L2-5; `docs/operator-apply-performance-latency-remediation.md` | 2026-07-29 | | ||
| | #191 | P3 | task | X5: ACL-migration consolidation (provider-gated) | **Outcome:** ACL-related migrations are consolidated per maturity work-order X5 without weakening owner-scope/RLS. **Next:** DB-owner approved window only; live-DB provider confirmation required before apply. **Stop:** no hosted apply from an agent session without explicit approval. | docs/maturity-backlog-workorders.md X5; #086 | 2026-07-31 | | ||
| | #231 | P2 | issue | Generation fallbacks no longer stick in answer cache; lithium generation quality still falls back safely | S1 (#2022), S1b (#2035), S1d (#2054) landed with green canary pairs: generation-quality false rejections and the finalizer gap hole are fixed. Residual R4: chronic ~30 s strong-route provider_timeout on metformin-renal-dosing and valproate-pregnancy (measured 4/4 at v18 4ea310e48 and 2/4 at v19 main on 2026-08-18; safe source-backed extractive fallback, never model synthesis). Route-budget stop condition unchanged. Remediation-plan Phase 5.2 (re-test #231 after the trigram-index restore) is satisfied by S1's 2026-08-17 healthy-latency probes; live-drift #316 Phase 1.2 classified all ten RPC divergences as attribute-only, so canaries since 2026-08-14 measure a reconstructable path. Re-graded P1 -> P2. Next: prompt/context trimming for complex classes, or accept the extractive fallback as the durable answer for these two classes. Do not add a separate R4 row — this update supersedes that need. | docs/rag-improvement/HANDOVER.md secs 1-2; docs/rag-improvement/COORDINATION.md sec 7; docs/database-remediation-plan.md Phase 5.2; docs/audit/live-drift-forensics-2026-08.md sec on Phase 1.2 classification; ledger rows #316 / #248 / #231 / #342; session 2026-08-18 | 2026-08-04 | | ||
| | #231 | P2 | issue | Generation fallbacks no longer stick in answer cache; lithium generation quality still falls back safely | PHASE 5.2 CONFIRMED SATISFIED with fresh data 2026-08-22 Perth (2026-08-21 UTC), not reopened. This row already recorded that remediation-plan Phase 5.2 is satisfied by S1's 2026-08-17 healthy-latency probes; the Phase 5 close-out re-measured production end to end and confirms it. Retrieval now costs 955 ms on the text fast path and 6,720 ms on hybrid (from 31,610 ms and 21,757 ms at the incident), against answerRouteBudgetMs.fast of 25,000 ms -- so retrieval consumes 4-27% of the fast budget and is no longer capable of binding it. The 2026-08-14 verdict that pre-generation latency WAS the binding cause stands for that window and is now closed out. Residual R4 (chronic ~30 s strong-route provider_timeout on metformin-renal-dosing and valproate-pregnancy, with a safe source-backed extractive fallback) is generation-side and unchanged; no separate R4 row was created, per this row's own instruction. INCONSISTENCY TO FIX AT RECONCILE: the recommended-execution-queue row for #231 still presents it as A1 / 'immediate approved live investigation' with the old framing ('live answers degrade to source-only when answerRouteBudgetMs.fast binds while retrieval is healthy'), which contradicts the P1 -> P2 re-grade recorded in this detail row. The queue entry should be re-graded to match P2 and re-scoped to the R4 generation-side residual, so the queue stops advertising a retrieval investigation that the measurements have closed. | docs/audit/live-drift-forensics-2026-08.md Phase 5 close-out 5.1(a) and 5.2; production probes 2026-08-22 Perth (2026-08-21 UTC) | 2026-08-04 | |
There was a problem hiding this comment.
When an operator follows the recommended queue, line 56 still sends them to an A1 “Immediate approved live investigation” for retrieval binding the fast-route budget, even though this updated row says retrieval now consumes only 4–27% of that budget and explicitly requires the queue to be re-graded to P2 and re-scoped to the generation-side R4 residual. Because the ledger owns recommended order and must be updated when work is materially re-scoped, leaving the old entry intact can trigger unnecessary provider work on an investigation this reconciliation declares closed. Update the queue entry as part of this transaction rather than merely recording the inconsistency.
AGENTS.md reference: AGENTS.md:L1130-L1137
Useful? React with 👍 / 👎.
Summary
Serialized reconcile of the 19 ledger requests queued since #2229's batch, run from a fresh base off
origin/main. Do not mergemaininto this branch — a reconciliation PR carries an exact transaction and the ledger contract forbids it.#316is CLOSED. That was the P1 tracking live drift — 20 missing repo-defined indexes, 10 divergent retrieval RPC bodies, and a weeklylive-driftjob red since 2026-07-26. Both original halves closed earlier; its last follow-on, Phase 5 measurement, completed in docs(db): Phase 5 close-out — measurement baselines, staging parity, and D4 settled to fact (#316) #2250, and the alarm was finally observed clear onlive-driftrun32514326022(first green since 2026-07-19, ending a 33-day red streak; pinned issue Live drift check failing #1963 auto-closed).#231updated. Plan §5.2 is confirmed satisfied against fresh data — retrieval now costs 955 ms (fast path) to 6,720 ms (hybrid) against a 25,000 ms budget, so it consumes 4–27% and can no longer bind it. The stale A1 "immediate approved live investigation" framing in the recommended queue is corrected to match the P2 re-grade recorded in the row's own detail.#316:supabase/**. Recorded with the context that CI'sMigration replayjob independently replays the whole chain, so preview branches are a second net rather than the only one.document_index_unitsretrieval path —explain_retrieval_rpcreaches only four RPC names and none touches that table — together with the absence of query-specific plan-flip evidence.ANALYZEthe better-supported explanation for the recovery. Recorded with an explicit caveat that a per-relation counter reset would be invisible to the database-widestats_resetread, so it is strongly supported rather than proven.Verification
Ledger-only change, so the gates that actually cover it were run directly rather than the full PR-local sweep, which is currently timing out on cross-worktree lock contention rather than on this diff.
npm run check:outstanding-issuesnpm run check:ledger-write-disciplinenpm run format(whole tree, result committed)Verification not run — lint, typecheck, unit suite, build, browser, and every eval: no executable scope. This diff changes the canonical ledger, its inbox, and the applied audit records only.
Risk and rollout
docs/outstanding-issues.mddirectly, and it allocates display ids. It was run from a freshorigin/mainbase under the reconcile lock, the transaction is recorded, and the guard confirms no ids were deleted from that base.git revertrestores the ledger and returns the requests to pending; the immutable request records are unchanged by a revert, so nothing is lost.Notes
#316closing does not close the programme's residual work, which stays on its own rows: PITR is still OFF on production, and the fifteen no-statements history rows remain#Q5JHBJ.