fix(review): stop recomputing the type label on review-family webhooks

[JSONbored]

Summary

• Follow-up to [Bug]: PR type label can silently downgrade gittensor:feature→gittensor:bug when a pull_request_review webhook races the merge webhook #4975/fix(review): resolve an ambiguous null prMergedAt with a live recheck before downgrading a label #4980: excludes pull_request_review, pull_request_review_comment, and pull_request_review_thread webhooks from the type-label recompute entirely. None of the three can ever change a PR's title or its linked-issue list — the only two inputs the label decision depends on — yet each was still reaching the recompute with its own independently-stale embedded PR snapshot, which is the exact mechanism feat(ui): confidence-calibration curve card on the analytics dashboard (#2192) #4818 exploited. fix(review): resolve an ambiguous null prMergedAt with a live recheck before downgrading a label #4980 fixed the one discovered symptom of that staleness (an ambiguous null prMergedAt); this shrinks the risk surface structurally so future not-yet-discovered staleness paths in these three event types can't reach the decision at all, rather than continuing to patch each one as it's found.
• Nothing is lost: a genuine title/linked-issue change is still caught by the next pull_request-native event (opened/reopened/synchronize/ready_for_review/edited/closed) or the periodic sweep — bounded delay, not a lost update.
• Also audited and confirmed clean (documented in [Bug]: type-label recompute unnecessarily runs on review-family webhooks, widening the #4818 staleness race #4986, no code change needed): the sweep/cross-reference path can't reach this block for a non-open PR; the manual panel-retrigger path reads a DB row (protected by this codebase's undefined-omits-the-column upsert convention), not a webhook snapshot; /pulls/{n}//issues/{n} reads are excluded from both the response cache and unsafe single-flight coalescing; exactly one code path writes these labels anywhere in src/.

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves (Closes #4986).

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally
• npm run test:workers
• npm run build:mcp
• npm run test:mcp-pack
• npm run ui:openapi:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

If any required check was skipped, explain why:

• test:coverage (full unsharded): not run end-to-end locally — ran scoped vitest --coverage for test/unit/queue-2.test.ts + test/unit/queue-5.test.ts (the two files that exercise this code path) and confirmed via lcov that every line/branch touched by this diff is covered (the one remaining 0-hit line in the surrounding function is a pre-existing, untouched catch block, not part of this change). Also ran npm run test:changed: 7949 tests passed. CI's own codecov/patch run is authoritative for the final number.
• test:workers / build:mcp / test:mcp-pack / ui:openapi:check / ui:lint / ui:typecheck / ui:build: not run — this change touches only src/queue/processors.ts and its test file, no UI/MCP/Worker-pool/OpenAPI-surface changes.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. (N/A — no auth/session surface touched; new tests explicitly cover the "review-family event, no fetch, no label write" negative path for all 3 excluded event types plus a combined regression test.)
• API/OpenAPI/MCP behavior is updated and tested where needed. (N/A.)
• UI changes use live API data or real empty/error/loading states. (N/A — no UI changes.)
• Visible UI changes include a UI Evidence section. (N/A — no UI changes.)
• Public docs/changelogs are updated where needed. (N/A — internal engine behavior; changelog is not edited in a normal PR.)

Notes

• Prompted directly by a question about why the type label was recomputing on a review-submission event in the first place — the honest answer was "it never needed to, it was just riding along on a bigger shared function with no relevance gate of its own." This PR adds that gate.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.32%. Comparing base (f175e0c) to head (e5d2282).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4987   +/-   ##
=======================================
  Coverage   94.31%   94.32%           
=======================================
  Files         455      455           
  Lines       39083    39086    +3     
  Branches    14256    14258    +2     
=======================================
+ Hits        36862    36867    +5     
+ Misses       1572     1570    -2     
  Partials      649      649           

Flag	Coverage Δ
shard-1	46.57% <80.00%> (-0.29%)	⬇️
shard-2	33.63% <80.00%> (+0.27%)	⬆️
shard-3	31.38% <20.00%> (+0.26%)	⬆️
shard-4	32.49% <40.00%> (-0.52%)	⬇️
shard-5	34.58% <20.00%> (+0.94%)	⬆️
shard-6	45.47% <40.00%> (+0.21%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/queue/processors.ts	95.34% <100.00%> (+0.07%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-11 07:33:36 UTC}

2 files · 1 AI reviewer · 2 blockers · readiness 75/100 · CI green · unstable

⏸️ Suggested Action - Manual Review

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Review summary
This PR extends #4980's fix by structurally excluding pull_request_review, pull_request_review_comment, and pull_request_review_thread events from the type-label recompute entirely, rather than just patching the one ambiguous branch #4818 exploited. The eventName is threaded through the webhook context into maybePublishPrPublicSurface, the skip check and skip-reason ternary both reuse a single isReviewFamilyEvent computation, and the tests exercise the real processJob path (asserting zero issue fetches and no label mutation) rather than fabricating an isolated unit scenario. The regression test's two-pass structure (real propagation on pull_request, then a stale-snapshot pull_request_review that must add nothing) is a good verification of the actual #4818 shape.

Nits — 3 non-blocking

• The wiring of `eventName` into the call-site object at src/queue/processors.ts:5648 is shown only as a partial hunk — worth double-checking in the full diff that every caller of maybePublishPrPublicSurface for review-family payloads actually threads the real GitHub event name through (sweep/manual-retrigger correctly omit it per the comment, but confirm no other pull_request_review* entry point bypasses handlePullRequestWebhookEvent).
• The inline comments on the new set and field are quite long (5+ lines each) for what the code does — consistent with this file's existing dense-comment style, but could be trimmed to the non-obvious rationale only.
• Consider a short follow-up note in the audit log/metrics for `irrelevant_review_family_event` skips so it's easy to distinguish 'legitimately irrelevant' skips from other skip reasons in dashboards, since this is a newly introduced category.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	⚠️ 3 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope	❌ 8/20	High review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 48 registered-repo PR(s), 40 merged, 420 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 48 PR(s), 420 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 48 PR(s), 420 issue(s).
• Related work: Titles/paths share 6 meaningful terms. (issue #4986)
• Related work: Titles/paths share 3 meaningful terms. (issue #4767, issue #4986)
• Related work: Titles/paths share 3 meaningful terms. (issue #4801, issue #4986)
• Additional title-only matches omitted; title-only overlap does not block.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Review top overlaps.
• Add a concise scope and risk note.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.
• Check active issues and PRs before submitting.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review