fix(review): reuse the live mergeable_state/CI read across a single pass

[JSONbored]

Closes #4498.

Summary

• reReviewStoredPullRequest and the direct pull_request webhook handler both thread ONE shared LiveGithubFacts object through readiness, maybePublishPrPublicSurface, and runAgentMaintenancePlanAndExecute — but the latter two independently force-refetched the same PR's mergeable_state and CI aggregate live from GitHub, back to back, with no GitHub-side mutation between the two reads (only a comment/labels get posted in between).
• Adds reuseOrRefreshLiveMergeState/reuseOrRefreshLiveCiAggregate, which reuse a value already populated by a FORCED write earlier in the same pass instead of re-fetching.
• Deliberately NOT the existing cachedLiveMergeState/cachedLiveCiAggregate variants (the audit's original suggestion) — those fall through to the durable cross-webhook cache on a request-local miss, which can replay an older webhook's snapshot. That's exactly what the disposition input's #4220 invariant (see the doc comment on refreshLiveMergeState) prohibits: the act-boundary disposition must never see a stale value. Verified this distinction matters empirically — an existing test ("a second agent-regate-pr pass for the SAME still-settled head_sha serves the readiness check from the durable cache...") broke against a naive cachedLiveMergeState-based fix and only passed once the fix correctly distinguished a genuinely-fresh forced write from a possibly-stale cached one.
• To make that distinction, LiveGithubFacts gains forcedMergeStateKeys/forcedCiAggregateKeys (Set<string>), populated only by the FORCED writers (refreshLiveMergeState/refreshLiveCiAggregate). The reuse helpers only trust a memoized value when its key is in these sets — never when it was populated by the READINESS path's own cache-preferring reader.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• 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.
• Owner PR resolving a maintainer-tracked issue (fix(review): PR mergeable-state + CI aggregate fetched live from GitHub twice per review pass #4498); no additional linked-issue-eligibility concern applies.

Validation

• npm run typecheck
• New invariant test added, empirically verified against the real bug: reverting the fix on the exact same fixture produces 3 live reads of each resource; with the fix, 2 (readiness's own separate, legitimate read is untouched by this fix — only the redundant third call is eliminated).
• An existing test that would catch an UNSAFE version of this fix (reusing a possibly-stale cached value) is still green — confirmed by first implementing a naive version, watching it break that test, then fixing it with the forced-key tracking described above.
• npx vitest run test/unit/queue.test.ts (759 passed) and the full unsharded suite npx vitest run (12,906 passed, 12 skipped) — run in full given this touches a widely-shared interface (LiveGithubFacts).

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.
• N/A — no auth/cookie/CORS/GitHub App/Cloudflare/session changes.
• N/A — no API/OpenAPI/MCP behavior changed.
• N/A — no UI changes.

[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.04%. Comparing base (86eeea0) to head (3b6e194).
⚠️ Report is 3 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4537   +/-   ##
=======================================
  Coverage   94.04%   94.04%           
=======================================
  Files         422      422           
  Lines       37579    37589   +10     
  Branches    13729    13733    +4     
=======================================
+ Hits        35340    35350   +10     
  Misses       1583     1583           
  Partials      656      656           

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

🚀 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-09 23:40:02 UTC}

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

⏸️ Suggested Action - Manual Review

• Touches a guarded path — held for manual review: This PR changes guardrail-protected path(s): src/queue/processors.ts (matched src/queue/**).

Review summary
The PR adds request-local `forcedMergeStateKeys`/`forcedCiAggregateKeys` sets so `reuseOrRefreshLiveMergeState`/`reuseOrRefreshLiveCiAggregate` can reuse a value populated by a genuinely-forced live refresh earlier in the same webhook pass, while still falling through to a real live fetch on any miss — correctly avoiding the durable cross-webhook cache that the removed direct `refreshLive*` calls were deliberately using to guarantee freshness per the #4220 invariant. The new test asserts exactly 2 live merge-state reads and 2 CI-aggregate reads (readiness's own miss + the disposition planner's reuse of `maybePublishPrPublicSurface`'s prior forced refresh) instead of 3, with commentary that reverting the fix reproduces 3 — a reasonably strong empirical demonstration. I can't see the full `runAgentMaintenancePlanAndExecute`/`maybePublishPrPublicSurface` call order in the truncated diff, so I can't independently confirm the forced refresh always precedes the reuse call within the same pass, but nothing in the visible code contradicts the PR's description.

Nits — 7 non-blocking

• The reuse-miss branch (no forced key present this pass, e.g. `unifiedCommentAllowed` false) isn't exercised by the new test — worth confirming an existing test already covers `reuseOrRefreshLiveMergeState`/`reuseOrRefreshLiveCiAggregate` falling through to a real refresh, not just the reuse-hit path.
• `reuseOrRefreshLiveMergeState` and `reuseOrRefreshLiveCiAggregate` (processors.ts) duplicate the same key-lookup-then-fallback shape; a small shared helper parameterized by the map/set pair could cut the repetition, though the differing signatures make this optional.
• The external secret scanner flag on `test/unit/queue.test.ts:18434` is a placeholder string literal in test fixture data (explicitly named to prove it must not leak), not an actual credential — no action needed, just noting it's a false positive.
• If convenient, point to (or add) a test asserting the fallback-to-live-refresh branch when no forced write happened yet in the pass, to fully cover both arms of the new reuse helpers.
• Consider a one-line comment at the `runAgentMaintenancePlanAndExecute` call site confirming which specific earlier call (in `maybePublishPrPublicSurface`) is expected to have populated the forced set, so the ordering dependency is locatable without cross-referencing the PR description.
• 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.
• 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	#4498
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: 48 registered-repo PR(s), 40 merged, 363 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 48 PR(s), 363 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Linked issue satisfaction

Addressed
The diff replaces the two redundant force-refresh calls in runAgentMaintenancePlanAndExecute with reuseOrRefreshLiveMergeState/reuseOrRefreshLiveCiAggregate, which reuse the value already forced-refreshed earlier in the same pass (tracked via new forcedMergeStateKeys/forcedCiAggregateKeys sets) and fall through to a genuine live refresh when no prior forced write exists, satisfying both the de-dup

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), 363 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