fix(storage): copy duplicate revisions' generation from their representative

[Sinity]

Summary

Duplicate revision decisions (byte-identical to another raw in the same
cohort) now record their true acquisition_generation (copied from their
representative) instead of always falling back to 0.

Problem

_expand_duplicate_decisions (polylogue/archive/revision_authority.py)
gives every duplicate member predecessor_raw_id=None. revision_governance .py's generation walk in classify_raw_revision_cohort builds a
predecessor-keyed dict ({decision.predecessor_raw_id: decision.raw_id for decision in decisions if decision.predecessor_raw_id is not None}) and
walks it from the baseline. Because duplicates never carry a
predecessor_raw_id, they never appear in that dict and never get visited
by the walk, so they fall back to acquisition_generation=0 regardless of
their representative's true chain position. Flagged by CodeRabbit review on
PR #3574 (polylogue-5unky).

The obvious fix — mirror the representative's predecessor_raw_id onto the
duplicate — was considered and rejected: it makes the duplicate and its
representative compete for the same key in the plain-dict comprehension
above. Whichever entry the comprehension writes last silently wins that
slot, so the duplicate can overwrite the real chain-continuing
representative and break generation numbering for everything downstream of
it. That would be a worse regression than the bug being fixed.

Severity is low: acquisition_generation on a duplicate row is a
display/ordering field, not something authority/replay-plan logic depends
on for duplicates. Still worth fixing correctly since this is a
safety-adjacent subsystem.

Solution

Implemented approach (b) from the two options the tracking bead named: a
separate post-pass that copies the representative's already-computed
generation, rather than folding duplicates into the predecessor-keyed walk
at all.

• Added HistoricalRevisionDecision.duplicate_of_raw_id: str | None
  (polylogue/archive/revision_authority.py), populated only for
  relation="duplicate" entries in _expand_duplicate_decisions, pointing
  at the representative raw_id. Deliberately kept separate from
  predecessor_raw_id -- a duplicate is not a chain-continuing child of
  anything, it's a second copy of its representative's own bytes, so it
  must never compete for a children dict slot.
• classify_raw_revision_cohort
  (polylogue/storage/sqlite/archive_tiers/revision_governance.py) now runs
  a post-pass after the real chain walk: for every relation="duplicate"
  decision, generation_by_raw_id[dup.raw_id] = generation_by_raw_id.get(dup.duplicate_of_raw_id, 0). Duplicates never
  participate in the predecessor-keyed walk.

Approach (a) (children-as-list, picking the chain-continuing child
specifically) was considered but doesn't fit the semantics as cleanly: a
duplicate isn't an additional child of the representative's predecessor,
it's the same generation as the representative itself.

Verification

• devtools test tests/unit/storage/test_revision_replay.py -k duplicate --
  2 passed. Both new tests were confirmed to fail against the pre-fix code
  (assert 0 == 1) by stashing the fix and rerunning, proving they exercise
  the real bug, then re-verified passing with the fix restored.
  • test_duplicate_decision_mid_chain_gets_representative_generation_not_zero:
    builds a 3-link byte chain (base -> mid -> head) plus a byte-identical
    duplicate of the middle link, proves the duplicate gets generation 1
    (mid's real position), not the 0 fallback.
  • test_duplicate_generation_copy_does_not_drop_the_chain_continuing_representative:
    constructs the exact collision shape the rejected fix would have hit --
    a duplicate of mid that is same-size and lexicographically later
    than mid (the ordering the rejected fix's dict comprehension would
    need to let the duplicate clobber mid's real predecessor-keyed slot)
    -- and proves head, two links downstream of mid, still gets its
    correct real generation (2), i.e. the true chain-continuing
    representative was never displaced from the walk.
• devtools test -k raw_authority -- 90 passed, 6 failed. All 6 failures
  are in test_raw_authority_scale_proof.py /
  test_raw_authority_daemon_health_proof.py (timeout-driven scale/daemon
  tests). Confirmed pre-existing and unrelated: reran
  test_raw_authority_scale_proof.py alone with this change stashed out and
  got the identical failure set.
• devtools verify --quick -- exit_code: 0, all 19 steps green (ruff
  format/check, mypy, render all, topology, layering, closure-matrix, schema
  roundtrip, manifests, ci-workflows, doc-commands, docs-coverage,
  test-infra-currency, pytest-timeout-overrides, degrade-loudly,
  hash-boundary-census, schema-versioning policy, classifier-fingerprints
  policy, schema promotion audit). Also ran again automatically via the
  pre-push hook -- green.

Ref polylogue-5unky

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 44 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: 7cb5294c-72d0-4c90-a8fd-cb334775d10c

📥 Commits

Reviewing files that changed from the base of the PR and between f992b11 and 4f98208.

📒 Files selected for processing (4)

• .beads/issues.jsonl
• polylogue/archive/revision_authority.py
• polylogue/storage/sqlite/archive_tiers/revision_governance.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.}