Skip to content

feat(dup-winner): name and link the surviving PR in the close comment posted to losing duplicate-cluster PRs #3817

Description

@JSONbored

Context

Found during the 2026-07-06 incident audit (parent: #1667), and directly related to the user's stated goal of contributors being "credited properly" and duplicate work being "handled gracefully."

Today, when a losing sibling in a duplicate cluster is gate-blocked/auto-closed (via isDuplicateClusterWinnerByClaim, see #(true-creation-time fix issue)), the close comment explains that another open PR already links the same issue, but does not name or link which specific PR won, so the closed contributor has to go hunt for it themselves (and has no way to easily verify their work wasn't simply lost/ignored).

Requirements

  • When closing a losing duplicate-cluster PR, include the winning PR's number and a direct link in the close comment/reason (e.g. "Closed as a duplicate of feat(orb): add POST /v1/orb/ingest central collector endpoint #1234, which linked this issue first — thank you for your work, feel free to open a PR against any remaining scope that feat(orb): add POST /v1/orb/ingest central collector endpoint #1234 doesn't cover.").
  • Ensure the winner's PR number is threaded through to wherever the close-reason/comment text is composed (the winner is already computed via isDuplicateClusterWinnerByClaim/openSiblingsForPr for gating purposes — this only requires surfacing which specific sibling number was the elected winner instead of just a boolean).
  • Add a test asserting the close comment for a losing PR contains the winning PR's number/link.

Deliverables

  • Wherever the duplicate-cluster close reason/comment is composed (near the processors.ts:7275 call site and its close-comment templating): include the winner's PR number/link.
  • Regression test asserting the generated close comment names the correct winning PR number.

Expected outcome

A contributor whose PR is closed as a duplicate immediately sees which specific PR won and can go verify their own contribution wasn't silently discarded, instead of just being told "another PR already exists" with no pointer to it.

Metadata

Metadata

Assignees

Labels

maintainer-onlyOwner-only work — yields no Gittensor points.

Projects

Status
Done

Relationships

None yet

Development

No branches or pull requests

Issue actions