Problem
Linked-issue label propagation (linkedIssueLabelPropagation) correctly copies gittensor:feature/gittensor:priority from a linked issue onto a PR while the issue is open. But merging a PR whose body says Closes #N auto-closes issue #N as an immediate side effect of that same merge. The propagation lookup (resolveIssueLabelsForPropagation, src/review/linked-issue-label-propagation-fetch.ts) only trusts an open linked issue, so the very next time the type-label decision runs for that PR (a near-simultaneous webhook delivery at merge time, or the periodic agent-regate-sweep), it finds the issue closed, propagation returns no labels, and the code falls back to a blunt title-regex classifier — which then removes the correct labels it had just applied and replaces them with gittensor:bug.
Evidence
Audit of github_app.type_label_decision events over 2026-07-07–2026-07-09 found 87 real downgrades (51 on gittensory, 36 on metagraphed). 79 are still wrong on live GitHub, and 39 permanently lost the gittensor:priority 1.75x reward multiplier. Confirmed live example: PR #4494, correctly labeled gittensor:feature+gittensor:priority from issue #4279 at 22:12 UTC, stripped to gittensor:bug at 22:15:38 UTC (25s after its own merge auto-closed #4279).
Fix
Extend the propagation trust condition: accept a closed linked issue when it was closed at or after this PR's own merged_at (i.e. closed as a byproduct of this exact PR's merge), not just when it's still open. An issue closed before this PR merged still doesn't count — that keeps the original anti-gaming intent (a PR can't borrow a label from some unrelated, already-resolved issue) fully intact.
Scope
Not fixing in this issue: a second, separate exposure where the periodic sweep re-evaluates a still-open PR whose linked issue was closed independently (not-planned/duplicate) by someone else. That's a distinct product-policy question (should an independently-closed issue's labels still apply to a PR still in flight?), not a clear bug — tracked separately if we decide to change that behavior.
Problem
Linked-issue label propagation (
linkedIssueLabelPropagation) correctly copiesgittensor:feature/gittensor:priorityfrom a linked issue onto a PR while the issue is open. But merging a PR whose body saysCloses #Nauto-closes issue #N as an immediate side effect of that same merge. The propagation lookup (resolveIssueLabelsForPropagation,src/review/linked-issue-label-propagation-fetch.ts) only trusts an open linked issue, so the very next time the type-label decision runs for that PR (a near-simultaneous webhook delivery at merge time, or the periodicagent-regate-sweep), it finds the issue closed, propagation returns no labels, and the code falls back to a blunt title-regex classifier — which then removes the correct labels it had just applied and replaces them withgittensor:bug.Evidence
Audit of
github_app.type_label_decisionevents over 2026-07-07–2026-07-09 found 87 real downgrades (51 on gittensory, 36 on metagraphed). 79 are still wrong on live GitHub, and 39 permanently lost thegittensor:priority1.75x reward multiplier. Confirmed live example: PR #4494, correctly labeledgittensor:feature+gittensor:priorityfrom issue #4279 at 22:12 UTC, stripped togittensor:bugat 22:15:38 UTC (25s after its own merge auto-closed #4279).Fix
Extend the propagation trust condition: accept a closed linked issue when it was closed at or after this PR's own
merged_at(i.e. closed as a byproduct of this exact PR's merge), not just when it's still open. An issue closed before this PR merged still doesn't count — that keeps the original anti-gaming intent (a PR can't borrow a label from some unrelated, already-resolved issue) fully intact.Scope
Not fixing in this issue: a second, separate exposure where the periodic sweep re-evaluates a still-open PR whose linked issue was closed independently (not-planned/duplicate) by someone else. That's a distinct product-policy question (should an independently-closed issue's labels still apply to a PR still in flight?), not a clear bug — tracked separately if we decide to change that behavior.