Skip to content

fix(storage): scope quarantine application lookup to this raw's own receipt - #3372

Merged
Sinity merged 1 commit into
masterfrom
fix/quarantine-application-history-scoping-zaiz
Jul 28, 2026
Merged

fix(storage): scope quarantine application lookup to this raw's own receipt#3372
Sinity merged 1 commit into
masterfrom
fix/quarantine-application-history-scoping-zaiz

Conversation

@Sinity

@Sinity Sinity commented Jul 28, 2026

Copy link
Copy Markdown
Owner

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_applications is 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 matched raw_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_raw requires byte-frontier authority by design and cannot resolve them. This is not a bug; it's a real architectural boundary. Recorded on polylogue-zaiz as 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 passed
  • mypy polylogue/storage/repair.py → clean
  • devtools verify --quick → exit 0

Ref polylogue-zaiz, polylogue-ihc8

Co-Authored-By: Claude noreply@anthropic.com

…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>
@coderabbitai

coderabbitai Bot commented Jul 28, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@Sinity, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 39 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 3cd82703-c314-4266-899e-2d7d22cff8f2

📥 Commits

Reviewing files that changed from the base of the PR and between 45434fa and 4609951.

📒 Files selected for processing (2)
  • polylogue/storage/repair.py
  • tests/unit/storage/test_quarantined_accepted_raw_repair.py
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/quarantine-application-history-scoping-zaiz

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@Sinity
Sinity merged commit 31eb8d8 into master Jul 28, 2026
3 checks passed
@Sinity
Sinity deleted the fix/quarantine-application-history-scoping-zaiz branch July 28, 2026 12:11
Sinity added a commit that referenced this pull request Jul 28, 2026
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant