fix(github): evict a rejected installation token on PR-mutating calls

[JSONbored]

What

mergePullRequest, closePullRequest, createPullRequestReview, updatePullRequestBranch, createIssueComment, and getLastCloserLogin in src/github/pr-actions.ts all called createInstallationToken directly and never routed through withInstallationTokenRetry (src/github/app.ts) — the only caller of expireCachedInstallationToken. Only the check-run creator and the comment poster in src/github/comments.ts got evict-and-retry.

An installation suspended, or the App private key rotated, while a cached token (kept up to ~1h) is still in the cache meant every merge/close/review/update-branch call for that installation kept reusing the same now-invalid token and re-failing with 401 each time — no self-heal, unlike the paths that already route through the retry helper. It would just keep failing until the cache's own TTL lapsed on its own.

Fix

Routed all six through withInstallationTokenRetry, mirroring the existing comments.ts pattern exactly: return withInstallationTokenRetry(env, installationId, async (token) => { ...the existing octokit call, unchanged... });. On a 401 (isGitHubBadCredentialsError), the helper evicts the cached token and retries once with a freshly-minted one — a suspended installation or rotated App key now self-heals on the very next attempt instead of failing repeatedly against a known-bad cached token for up to an hour.

getLastCloserLogin keeps its existing outer try/catch (fail-closed to { login: null, coveredAllPages: false } on any unrecoverable error) — the retry now happens inside that try, so a persistent 401 after the retry still degrades the same way it always has.

Deliberately out of scope: createPullRequestReviewComments (not in the issue's list — it takes a mode: AgentActionMode parameter and is used for lower-stakes inline review notes) and any other caller of createInstallationToken elsewhere in the codebase. createInstallationToken itself is still imported/used for that one function, unchanged.

Tests

• New test: closePullRequest receives a 401 on the first attempt, succeeds on the retry with a freshly-minted token — asserts exactly 2 close attempts and 2 token mints (proving the stale token was evicted, not reused).
• 2 new tests closing coverage gaps the refactor's re-indentation surfaced in pre-existing, unrelated logic (updatePullRequestBranch's expectedHeadSha ternary TRUE branch; getLastCloserLogin's lastPage <= 1 branch, both directions of its ?? null fallback).
• npx tsc --noEmit clean.
• Scoped: github-pr-actions.test.ts — 22 passed.
• Regression sweep: agent-action-executor.test.ts, agent-approval-queue.test.ts, routes-agent-approval.test.ts (direct importers), full queue.test.ts + inline-comments.test.ts — 317 passed combined.
• Diff-range coverage-gap check on src/github/pr-actions.ts: fully covered.
• Full unsharded npm run test:coverage: 5634 passed, 4 skipped (pre-existing/unrelated), 0 failed.
• npm audit --audit-level=moderate: 0 vulnerabilities.

Advances #1936. Closes #2263.

[loopover-orb]

Warning

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

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-02 00:45:13 UTC}

2 files · 1 AI reviewer · no blockers · readiness 93/100 · CI pending · blocked

⏸️ Suggested Action - Manual Review

• Touches a guarded path — held for manual review

Review summary
The change consistently routes the PR action wrappers through `withInstallationTokenRetry`, so a 401 from a cached installation token now evicts and retries on the affected paths while preserving the existing request payloads and fail-closed catches. The wrapping is mechanically correct in the provided file, including the multi-request lookup helpers where retrying the whole read-only scan is safe. The notable issue is process/documentation drift: the PR description says `createPullRequestReviewComments` is deliberately out of scope, but the diff changes and tests that path.

Nits — 7 non-blocking

• nit: The PR description is stale because `src/github/pr-actions.ts:createPullRequestReviewComments` is now routed through `withInstallationTokenRetry` despite the description saying it is deliberately out of scope.
• nit: The new retry tests in `test/unit/github-pr-actions.test.ts` start from an empty cache, so their comments describe a stale cached token even though the first rejected token is minted inside the same call rather than pre-seeded as stale.
• Update the PR description to list `createPullRequestReviewComments` as covered, or remove that code/test change if it is truly out of scope.
• For one retry regression in `test/unit/github-pr-actions.test.ts`, pre-seed the cache with an initial successful call or adjust the test wording so it matches the real exercised path.
• 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.
• AI maintainer-assist flagged possible low-effort patterns (elevated) — Advisory only — review the noted patterns; this AI assist never blocks the gate.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#2263
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 (size label size:L; 1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 65 registered-repo PR(s), 55 merged, 572 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 65 PR(s), 572 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 65 PR(s), 572 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Triage stale or unlinked PRs.
• No action.

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.90%. Comparing base (bef2d67) to head (aa68022).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2406   +/-   ##
=======================================
  Coverage   95.90%   95.90%           
=======================================
  Files         224      224           
  Lines       25217    25217           
  Branches     9169     9169           
=======================================
  Hits        24185    24185           
  Misses        419      419           
  Partials      613      613           

Files with missing lines	Coverage Δ
src/github/pr-actions.ts	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

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

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	gittensory-ui	54c2275	Commit Preview URL Branch Preview URL	Jul 02 2026, 12:37 AM