fix(storage): scope quarantine application lookup to this raw's own receipt - #3372
Conversation
…eceipt ## Problem Discovered live 2026-07-28, after deploying PR #3371 (which fixed the fan-out head/session scoping bug): the 3 real stuck sessions still failed inspection, now with "competing raw-revision application authority exists" instead of the earlier scoping crash. Root-caused via a stopped- daemon read-only diagnostic: `raw_revision_applications` is an append-only decision history (per `_inspect_duplicate_raw_identity`'s own docstring -- an immutable row, not a single-current-state table), so any session with more than one historical revision-authority decision accumulates multiple rows for the same logical_source_key. The lookup matched `raw_id = ? OR accepted_raw_id = ?`, which additionally pulls in rows from OTHER raw_ids' own receipts that happen to cite this raw as their superseded predecessor -- not just fan-out siblings, any session with real revision history hits this. ## Solution Scope the lookup to `raw_id = ? AND logical_source_key = ?` alone, finding only the one receipt that actually decided this raw's own acceptance for this session, not every historical receipt that ever mentioned it. New regression test seeds a legitimate prior superseded decision (an earlier, unrelated raw superseded in favor of this one) and confirms the session still classifies as eligible. Anti-vacuity: reverting the fix reproduces the exact "competing" failure. Applying this fix against the LIVE archive (read-only diagnostic) advanced all 3 stuck sessions past this check, to a further, genuinely different and definitive classification: `accepted_frontier_kind='semantic'` (not `'byte'`) -- these sessions were originally accepted under semantic equivalence, not a byte-proof. `refine_quarantined_raw` requires byte- frontier authority by design (it proves the RAW'S BYTES are exactly what was accepted); a semantically-accepted session cannot be resolved by this actuator at all. This is not a bug -- it's a genuine architectural boundary between byte-proof and semantic-equivalence acceptance, and resolving it needs either a semantic-frontier-aware actuator (a real, separate feature) or fresh reacquisition, not a scoping fix. Recorded on polylogue-zaiz as the definitive final answer for these 3 sessions. ## Verification - `devtools test tests/unit/storage/test_quarantined_accepted_raw_repair.py tests/unit/storage/test_duplicate_raw_identity_repair.py tests/unit/storage/test_raw_authority_ledger.py` -> 53 passed - `mypy polylogue/storage/repair.py` -> clean - `devtools verify --quick` -> exit 0 - Confirmed against the live archive (read-only): all 3 stuck sessions now progress past the application-history check to their genuine, final classification Ref polylogue-zaiz, polylogue-ihc8 Co-Authored-By: Claude <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 39 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…ile sg80 polylogue-zaiz's own scope (fan-out scoping bugs) is fixed and confirmed live via PRs #3371 and #3372. The 3 remaining stuck sessions have a definitive, non-bug explanation: accepted_frontier_kind='semantic', which refine_quarantined_raw cannot resolve by design. Filed polylogue-sg80 for the genuinely separate semantic-frontier-aware actuator design question. Co-Authored-By: Claude <noreply@anthropic.com>
Summary
Fix the next layer found while completing polylogue-zaiz's investigation: after PR #3371's fan-out scoping fix, the 3 real stuck sessions still failed inspection with "competing raw-revision application authority exists". This reveals the true final classification for these sessions.
Problem
raw_revision_applicationsis an append-only decision history, not a single-current-state table. Any session with more than one historical revision-authority decision accumulates multiple rows for the same logical_source_key. The lookup matchedraw_id = ? OR accepted_raw_id = ?, additionally pulling in rows from OTHER raw_ids' own receipts that cite this raw as their superseded predecessor.Solution
Scope the lookup to
raw_id = ? AND logical_source_key = ?alone. New regression test seeds a legitimate prior superseded decision and confirms eligibility is unaffected; anti-vacuity confirmed by reverting.Definitive finding
Applying this fix against the live archive (read-only) advances all 3 stuck sessions to their genuine final classification:
accepted_frontier_kind='semantic', not'byte'. These sessions were originally accepted under semantic equivalence, not a byte-proof —refine_quarantined_rawrequires byte-frontier authority by design and cannot resolve them. This is not a bug; it's a real architectural boundary. Recorded onpolylogue-zaizas the definitive answer — resolving it needs a semantic-frontier-aware actuator (a separate feature) or fresh reacquisition, out of scope here.Verification
devtools test tests/unit/storage/test_quarantined_accepted_raw_repair.py tests/unit/storage/test_duplicate_raw_identity_repair.py tests/unit/storage/test_raw_authority_ledger.py→ 53 passedmypy polylogue/storage/repair.py→ cleandevtools verify --quick→ exit 0Ref polylogue-zaiz, polylogue-ihc8
Co-Authored-By: Claude noreply@anthropic.com