fix(storage): exclude byte-identical duplicates from revision baseline tie-break

[Sinity]

Summary

Fixes a cross-feature interaction between PR #3574 (byte-identical duplicate collapse) and the pre-existing (#3406) membership-census guard: a duplicate of the accepted revision baseline could make plan_revision_replay misclassify a cohort with one unambiguous baseline as ambiguous, which then routed backfill/rebuild into a fallback path that tripped ActiveByteRevisionChainError.

Problem

PR #3574 collapses byte-identical full-revision captures into one representative plus "duplicate" decisions. A follow-up fix (#3580) made a duplicate's acquisition_generation mirror its representative's generation for correct display ordering. Together these made a duplicate of the accepted baseline/head share that node's generation number.

plan_revision_replay (polylogue/archive/revision_replay.py) selects the unique baseline by finding the single FULL, byte-proven candidate with the newest acquisition_generation. A duplicate sharing that generation now looked like a second competing baseline, so the tie-break declared the cohort ambiguous and returned an empty accepted_raw_ids for a cohort that in fact has one unambiguous baseline.

Backfill/rebuild callers (sources/revision_backfill.py) treat an empty accepted_raw_ids as "no accepted chain" and fold every full-only raw for the identity into membership governance via replace_raw_membership_census(..., retire_full_revision_governance=True). That path's guard then raised ActiveByteRevisionChainError the moment it tried to retire the baseline raw, because the duplicate's own baseline_raw_id column still durably points at it.

Confirmed via git log -S "ActiveByteRevisionChainError" that the guard itself is unchanged since #3406; the trigger is #3574/#3580's newly-created generation-sharing shape, not the guard.

Solution

The guard is correct and intentionally strict: a raw genuinely still pointed at by another raw's predecessor_raw_id/baseline_raw_id must not be retired out of byte governance (a real dependent chain shouldn't lose its baseline out from under it). The defect is upstream, in plan_revision_replay's inability to distinguish a harmless duplicate from a genuinely competing baseline.

A FULL, byte-proven candidate with no predecessor_raw_id that is NOT itself the cohort's baseline_raw_id can only be such a duplicate -- the classifier that writes these columns (archive/revision_authority.py) guarantees at most one true root per cohort (relation="baseline"). plan_revision_replay now excludes that signature from the baseline candidate pool via _is_full_duplicate_signature; excluded duplicates still fall through to the existing trailing loop and are marked DEFERRED against whatever head the genuine evidence accepts.

No schema change; this is a pure classification/replay-planning fix in polylogue/archive/revision_replay.py, shared correctly by both the backfill/rebuild path (revision_governance.classify_raw_revision_cohort) and the live watcher (sources/live/batch.py), which both build RevisionCandidate lists from the same raw_sessions columns.

Verification

• devtools test tests/unit/sources/test_revision_backfill.py::test_backfill_content_cache_across_pages_reduces_parses_and_matches_uncached_archive tests/unit/storage/test_rebuild_paging_content_order.py::test_rebuild_content_order_paging_dedups_first_time_classification_via_content_cache -- 2 passed (previously failing with ActiveByteRevisionChainError; this is the reproduction the tracking item names).
• devtools test tests/unit/storage/test_revision_replay.py tests/unit/storage/test_raw_revision_authority.py tests/unit/sources/test_revision_backfill.py tests/unit/storage/test_rebuild_paging_content_order.py tests/unit/sources/test_live_batch_support.py -k "revision or membership or duplicate or backfill or paging" -- 127 passed.
• Full-file runs of the same five files -- 169 passed, 3 pre-existing failures in test_live_batch_support.py confirmed identical with this change reverted (git stash); unrelated to this fix.
• Red-first: the two new tests in test_revision_replay.py were confirmed failing against the unpatched revision_replay.py (git stash), then passing after the fix.
• devtools verify --quick -- exit 0 (format, lint, mypy --strict, render all --check, layering, closure-matrix, schema roundtrip, schema-versioning, classifier-fingerprints, schema-promotion-audit, etc., all passed).

Anti-vacuity: the failing production path exercised is sources/revision_backfill.py's if not plan.accepted_raw_ids: fallback into archive.replace_raw_membership_census(..., retire_full_revision_governance=True); the mutation that makes the new tests fail is reverting the _is_full_duplicate_signature exclusion in plan_revision_replay (confirmed via git stash on polylogue/archive/revision_replay.py alone). The guard invariant itself (a real dependent chain must block retirement) is separately re-asserted inside the new archive-level test by calling replace_raw_membership_census directly and expecting ActiveByteRevisionChainError, and is unaffected by this change (pre-existing test_membership_sweep_defers_sibling_retirement_instead_of_quarantining_current_raw in test_live_batch_support.py still passes unmodified).

Ref polylogue-qhk8z

Scope not addressed

None -- this closes the full interaction described in the tracking item (root-cause fix in the replay planner, not a guard loosening), with a regression test reproducing the exact reported failure plus a unit-level test pinning the underlying tie-break defect.

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 49 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: f268f352-e860-4c28-acf5-9ad719a6ca4b

📥 Commits

Reviewing files that changed from the base of the PR and between 0cc65e7 and aff0e40.

📒 Files selected for processing (2)

• polylogue/archive/revision_replay.py
• tests/unit/storage/test_revision_replay.py

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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