fix(publication): coalesce duplicate result lineages

[snowzlmbot]

Summary

• enforce one effective queued publication lineage for a protocol-v2 exact review tuple: targetRepo#itemNumber + leaseRevision + claimGeneration;
• preserve producer run id/attempt as artifact provenance, while preventing a retry or duplicated artifact from a different producer for the same reviewed tuple from creating another queue chain;
• preserve the established same-producer redelivery behavior, including a newer queue revision owned by the same batch lease;
• protect dispatching, leased, and durable-batch-owned items from replacement or cancellation;
• retain pending/parked queue retry state while refreshing it with a newer equivalent producer artifact;
• expose semantic_deduped_total and time-window flow telemetry separately from stale-revision supersession;
• document the lane boundary, ownership rule, and reporting contract.

Fixes #800.

Problem

The queue key for result publication includes producerRunId and producerRunAttempt. Two artifact deliveries from different producer attempts for the same already-reviewed lease can therefore occupy distinct queue records. Existing controls dedupe identical delivery ids, supersede an older review revision, and avoid duplicate target items inside one batch, but they do not collapse equal review tuples across the full pending queue.

During a publication backlog, this creates avoidable preparation, state-writer, and GitHub mutation pressure without adding a new review decision. It also lets the queue count grow from repeated producer attempts even though there should be one visible final review result.

Behavior

The new semantic identity applies only to publication results for protocol-v2 tuples.

• An equivalent item from another producer already owned by a batch, dispatch, or lease remains authoritative. The later delivery is acknowledged as deduplicated and cannot alter the owner.
• For an equivalent pending or parked item from another producer, the queue slot and retry/failure history remain intact while producer provenance is refreshed to the later artifact. This prefers an available artifact without resetting failure budgets.
• Other pending/parked equivalent legacy records are removed and recorded as superseded queue work.
• Redelivery from the same producer run and attempt keeps the pre-existing queue-revision behavior; the active batch can preserve and requeue that newer revision after its owned completion.
• A different review revision remains a separate tuple and follows existing stale-revision fencing.
• Review, comment-routing, apply, and command lanes do not share this identity and are never cancelled merely because their issue/PR number matches.

Safety and scope

This does not change Codex prompts, review criteria, close/merge policy, batch ownership, state-writer coordination, GitHub write authorization, or per-item tuple fences. It does not raise batch size or concurrency.

An active publisher is deliberately immutable for a different producer: its batch membership and callbacks keep the original key and immutable ownership tuple. The change only absorbs later equivalent ingress. Same-producer redelivery retains the existing newer-revision path required by batch completion fencing.

Code paths

• dashboard/exact-review-queue.ts
  • derives the immutable publication lineage;
  • coalesces different-producer equivalents at enqueue;
  • protects active ownership and keeps retry state;
  • records cumulative and time-window semantic-dedupe telemetry.
• test/dashboard-worker.test.ts
  • proves pending-lineage coalescing and active-batch protection.
• test/exact-review-publication-batches.test.ts
  • aligns the 101-delivery cleanup regression with the new single-lineage invariant while retaining newer-revision batch coverage.
• docs/state-publication-batching-plan.md
  • documents lineage identity, lane isolation, ownership, and telemetry.

Validation

Local work was limited to lightweight static preflight:

• git diff --check: passed;
• oxfmt --check dashboard/exact-review-queue.ts test/dashboard-worker.test.ts test/exact-review-publication-batches.test.ts: passed;
• focused oxlint on the same files with --deny-warnings: 0 warnings, 0 errors.

Current-head cloud validation for ba6853923507fa3f2b8f1b3ffeb2be69d6a1d5c7:

• CI run 29979983902: full pnpm check, Windows launcher, sparse repair build smoke, and crawl-remote integration passed;
• CodeQL run 29979983911: Actions and JavaScript/TypeScript analyses passed;
• all current-head PR checks are terminal and successful, apart from the intentionally skipped notification job.

Failure-to-pass evidence:

• run 29978745022 exposed the established same-producer/newer-revision contract; the implementation was narrowed to different producers;
• run 29979518925 exposed the old 101-duplicate test expectation; the regression now verifies 100 semantic dedupes and one latest batch candidate;
• run 29979983902 then passed the full current-head check.

Risk

• Refreshing provenance for a pending/parked equivalent item could select a newer artifact that later becomes unavailable. Retry history is deliberately retained, and the existing artifact-refresh recovery remains the fallback.
• Treating equal tuples as one chain is only enabled for protocol-v2 publications with both immutable tuple fields present. Legacy items retain their original keys and behavior.
• Active batch, dispatching, and leased items from another producer are never mutated, so an in-flight publisher retains its original fenced callback contract.
• Same-producer deliveries are intentionally excluded from semantic coalescing because current batch completion relies on their queue-revision relationship.

Rollback

Revert commit ba6853923507fa3f2b8f1b3ffeb2be69d6a1d5c7. The change is additive: no queue schema-version bump, no external migration, and no configuration change. Existing queue records and active callbacks remain readable through their original keys.

Docs updated

• docs/state-publication-batching-plan.md

Related work

• fix(publication): coalesce duplicate exact-result lineages before batch claim #800 — queue-wide publication lineage deduplication
• fix(review): supersede stale exact-review runs #749 — supersede stale active exact-review runs before publication
• Serialize duplicate publication items within batches #772 — batch-local duplicate target protection
• RFC: single-writer state materialization via the queue DO (retire git-lease concurrency) #738 — durable state writer/materializer convergence

Not tested / limitations

• No production deployment or live queue mutation was performed from this branch.
• Backlog reduction depends on merge and deployment; this PR prevents new semantic duplicate pressure but does not claim to erase all historical non-duplicate publication work by itself.
• Maintainer review and deployment observation remain authoritative for rollout readiness.

[snowzlmbot]

@clawsweeper review-pr

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Review in progress
• Detail: The exact-review queue leased this run; Codex is reviewing the item.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/29981847501
• Updated: 2026-07-23T05:20:08.889Z

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this pull request: fix(publication): coalesce duplicate result lineages This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

[vincentkoc]

P1: dashboard/exact-review-queue.ts:716-749 only returns the semantic-deduplication result when producerChanged is true. After producer B replaces producer A, the retained map key remains A's key while retained.item.decision now contains B's provenance. A retry from B therefore misses exact-key delivery dedupe, finds the retained semantic lineage, computes producerChanged === false, skips this block, and is admitted as a second pending item under B's key. Both rows can then become publication work.

Return the semantic-deduplication result whenever a retained lineage exists; use producerChanged only to decide whether to refresh the retained decision/provenance. Add a regression covering A -> B replacement -> B retry and prove the queue still contains one effective lineage.

This recreates the duplicate publication chains the PR is intended to eliminate, so it must be fixed before merge.

[steipete]

Superseded by #807.

The original report from @snowzlmbot automation identified a real publication-lineage problem, but the submitted head recreated duplicate work on a refreshed producer retry. The maintainer replacement keeps the report credit, adds that regression plus legacy ordering coverage, and preserves the existing same-producer batch handoff contract.