test(github): cover the assignee-403 fallback and its unrelated-error guard (#4999)

[JSONbored]

Summary

• Fixes fix(review): ensurePullRequestAssignee always fails against GitHub App installation tokens (198 Sentry events) #4999: ensurePullRequestAssignee was reported failing 100% of the time against GitHub App installation tokens (198 Sentry events, GITTENSORY-1G).
• Investigated before writing anything: this was already fixed by #4167 (merged 2026-07-08T09:15:47Z), which added the exact catch Sentry Seer suggested — ensurePullRequestAssignee (src/github/assignees.ts:51-75) already detects GitHub's specific "Assigning agents is not supported with GitHub App installation tokens" 403 and returns { applied: false } instead of throwing, letting performAction fall through to its existing per-login label fallback.
• Confirmed via Sentry directly rather than assuming the fix landed cleanly: the issue's last occurrence was 2026-07-08T18:59:01Z on release gittensory-orb@0.4.0-beta.5 — every event predates or is from a build that predates the fix reaching a deployed release. The self-host box's current release (gittensory-selfhost@a43c918e, confirmed via a separate, more recent Sentry issue) is built from a commit descending from fix(github): gracefully handle GitHub App agent assignment 403 #4167. Zero occurrences of this error since. This satisfies deliverable chore(release): prepare public gittensory launch #2 ("confirm via Sentry after deploy that this specific error stops recurring").
• What was actually missing: fix(github): gracefully handle GitHub App agent assignment 403 #4167 shipped the fix with no regression test for the catch itself — test/unit/github-assignees.test.ts had zero coverage on assignees.ts:63-74 (confirmed via lcov: BRF:24 BRH:14 before this PR → the whole catch/throw branch was dead in tests). That's deliverable feat(docs): add install site and mcp diagnostics #1 ("regression test reproducing this exact error and asserting the fallback fires") and issue requirement feat(scoring): add situational score projections #3 ("don't swallow other errors — a genuine transient failure should still surface"), both still open. This PR adds exactly those two tests. No production code change — src/github/assignees.ts is untouched.
• Requirement chore(release): prepare public gittensory launch #2 ("confirm the caller falls through to a label-based equivalent") was already covered independently: test/unit/agent-action-executor.test.ts:854 ("falls back to a per-login label when GitHub silently drops an ineligible assignee") already exercises performAction's applied:false → label-fallback path end-to-end.

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 #4999).

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 — ran scoped vitest --coverage for test/unit/github-assignees.test.ts and confirmed via lcov that src/github/assignees.ts is now at 100% line and branch coverage (LF:20 LH:20, BRF:24 BRH:24).
• actionlint / test:workers / build:mcp / test:mcp-pack / ui:openapi:check / ui:lint / ui:typecheck / ui:build / npm audit: not run — this PR adds tests only, under test/** (Codecov-exempt), with no src/** change and no workflow, MCP, UI, or dependency-manifest surface touched.

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 surface changed; this PR only adds tests for an already-shipped fallback.)
• 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.)
• Visible UI changes include a UI Evidence section. (N/A.)
• Public docs/changelogs are updated where needed. (N/A — internal engine behavior; changelog is not edited in a normal PR.)

Notes

Part of a batch of 13 bug fixes filed from a Sentry-issue triage this session (#4994–#5006). This is #6 by priority — the underlying bug was already fixed by #4167 before this triage; this PR closes the remaining test-coverage gap.

[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.33%. Comparing base (214b4c3) to head (a00c0a2).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5038      +/-   ##
==========================================
+ Coverage   94.32%   94.33%   +0.01%     
==========================================
  Files         460      460              
  Lines       39303    39303              
  Branches    14338    14338              
==========================================
+ Hits        37073    37077       +4     
+ Misses       1575     1571       -4     
  Partials      655      655              

Flag	Coverage Δ
shard-1	46.43% <ø> (-0.28%)	⬇️
shard-2	33.62% <ø> (+0.26%)	⬆️
shard-3	31.35% <ø> (-0.12%)	⬇️
shard-4	32.57% <ø> (-0.25%)	⬇️
shard-5	34.33% <ø> (+0.89%)	⬆️
shard-6	45.40% <ø> (+0.31%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1 file with indirect coverage changes

🚀 New features to boost your workflow:

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

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-11 09:55:30 UTC}

1 file · 1 AI reviewer · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a pure test-only PR: it adds two regression tests to test/unit/github-assignees.test.ts covering the catch block in ensurePullRequestAssignee (src/github/assignees.ts:51-75) that already handles GitHub's 'Assigning agents is not supported with GitHub App installation tokens' 403 by returning {applied:false}, plus a test confirming an unrelated 403 still propagates. No production code is touched, consistent with the PR description's claim that the fix already shipped in #4167 and only test coverage was missing. The new tests stub fetch to return the exact GitHub error shape the existing catch checks for (status 403 + message.includes("Assigning agents is not supported")), so they exercise the real reachable path rather than fabricating an impossible state, and they close a genuine coverage gap (lcov showed BRF:24 BRH:14 on that branch pre-PR).

Nits — 5 non-blocking

• The four fetch stubs across this file (including the two new ones) repeat the same access_tokens/issues/4-GET boilerplate — worth extracting into a shared helper to cut duplication.
• The external scanner's 'generic_secret_assignment' flags on `token: "installation-token"` (lines 82/107) are false positives — it's a hardcoded test fixture string, not a real credential, but worth a quick glance to confirm nothing sensitive is actually there.
• Extract a small `stubAssigneeFetch({ postStatus, postBody })`-style helper given how many near-identical fetch stubs this file now has.
• Consider a follow-up assertion that the agents-403 fallback path doesn't accidentally match a differently-worded but unrelated GitHub message containing similar substrings, to guard the string-match condition itself.
• PR author also opened the linked issue — Link an issue that was opened by a different contributor, or provide a rationale for why this self-authored issue represents genuine discovery work.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#4999
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 47 registered-repo PR(s), 39 merged, 428 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 47 PR(s), 428 issue(s).
Gate result	✅ Passing	No configured blocker found.
Improvement	⚠️ ℹ️ Insufficient signal	risk: clean · value: insufficient-signal — Nothing measurable for the structural-improvement analyzers on this PR (e.g. no code files changed). LLM value judgment: moderate — The PR adds real regression coverage for a previously untested but already-shipped fix and its unrelated-error guard, directly closing the two open test-coverage deliverables from issue #4999 without touching production code.

Linked issue satisfaction

Addressed
The production fix (catching the specific 403 and returning applied:false) already landed in #4167 before this PR, and this PR adds the missing regression tests confirming both the fallback-on-specific-error and the propagation-of-unrelated-error requirements from the issue, with Sentry-based confirmation that the error stopped recurring in production.

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: 47 PR(s), 428 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.

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

[loopover-orb]

Gittensory approves — the gate is satisfied and CI is green.