fix(github): paginate GraphQL PR-detail fallback past 100 nodes

[galuis116]

Summary

• fetchPullRequestDetailsFromGraphQl (the GraphQL fallback used by fetchPullRequestFiles/fetchPullRequestReviews when the REST-side githubPaginatedList fails to fetch page 1) requested files(first: 100) and reviews(first: 100) with no pageInfo, so a PR with more than 100 changed files or more than 100 reviews was silently truncated with no way to even detect it — unlike the REST path, which already follows Link: rel="next" up to PR_DETAIL_MAX_PAGES = 10 pages.
• Added pageInfo { hasNextPage endCursor } to both the files and reviews GraphQL connections, and now walk each connection independently with cursor pagination (after: <cursor>), bounded by a new PR_DETAIL_GRAPHQL_MAX_PAGES = 10 constant next to the function (same 10-page/1,000-item ceiling as the REST path's PR_DETAIL_MAX_PAGES).
• A later-page GraphQL failure keeps the items already fetched instead of discarding everything, mirroring githubPaginatedList's existing "keep a successful partial result" semantics. A page-1 failure still throws/propagates exactly as before, so the function's total-failure contract to fetchPullRequestFiles/fetchPullRequestReviews (which .catch(() => undefined) this call and fall back to a warning + empty result) is unchanged.
• Updated GitHubPullRequestDetailsResponse's type to carry pageInfo for both connections.

Closes #7453

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 (e.g. Closes #123) — a linked open issue is required for every contributor PR.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally; codecov/patch requires ≥99% coverage of the lines AND branches you changed (aim for 100% on your diff so CI variance does not fail near the threshold). Global coverage is a non-blocking trend with a loose 90% backstop, not the gate.
• 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:

• npm run typecheck (whole-repo tsc --noEmit) reliably OOMs on this shared sandbox. Instead I ran a scoped tsc --noEmit against src/github/backfill.ts, src/env.d.ts, worker-configuration.d.ts, and the two changed/affected test files using the root tsconfig.json's exact compiler flags (strict, exactOptionalPropertyTypes, noUncheckedIndexedAccess, noImplicitOverride, noFallthroughCasesInSwitch, forceConsistentCasingInFileNames, skipLibCheck, target/lib/module/moduleResolution/types matching root config) — zero errors.
• test:workers, build:mcp, test:mcp-pack, ui:openapi:check, ui:lint, ui:typecheck, ui:build are not applicable: this change is confined to src/github/backfill.ts (a Worker-side GraphQL query) and its unit tests — it touches no Cloudflare Worker entrypoints, MCP package, OpenAPI schema, or apps/loopover-ui/** code.
• Coverage note: the changed lines inside fetchPullRequestDetailsFromGraphQl sit within the function's pre-existing /* v8 ignore start/stop */ block (already excluded from Codecov before this PR, per its own comment: "GitHub detail GraphQL sparse-node fallbacks are exercised through PR detail hydration tests"). They are exercised by the two new regression tests below but are not counted toward the branch-coverage percentage, matching the file's existing convention for this fallback.

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/cookie/CORS/session changes.)
• API/OpenAPI/MCP behavior is updated and tested where needed. (N/A change is internal GitHub GraphQL query pagination only; no public API/OpenAPI/MCP surface changed.)
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks. (N/A — no UI changes.)
• Visible UI changes include a UI Evidence section below with screenshots. (N/A — no visible UI changes.)
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

UI Evidence

N/A — backend-only change, no visible UI/frontend/docs changes.

Notes

• Two new regression tests were added to test/unit/backfill.test.ts, mirroring the existing backfillOpenPullRequestDetails GraphQL-fallback test shape:
  1. paginates the GraphQL PR-detail fallback past 100 files instead of truncating at the first page (#7453) — a two-page fixture (100 files + 1 file on a second page reached via a mocked after: "files-page-2" cursor) asserts all 101 files are persisted, not truncated at 100.
  2. does not send a second GraphQL PR-detail page when the fallback's files/reviews already fit on page one — asserts the existing single-page (hasNextPage: false) behavior is unaffected and no extra GraphQL request is made.

[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 91.39%. Comparing base (1370f24) to head (f619c55).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7493      +/-   ##
==========================================
- Coverage   91.41%   91.39%   -0.02%     
==========================================
  Files         717      717              
  Lines       73032    73033       +1     
  Branches    21636    21636              
==========================================
- Hits        66762    66752      -10     
- Misses       5227     5234       +7     
- Partials     1043     1047       +4     

Flag	Coverage Δ
shard-1	30.86% <100.00%> (+<0.01%)	⬆️
shard-2	39.73% <100.00%> (-0.02%)	⬇️
shard-3	36.08% <100.00%> (+<0.01%)	⬆️
shard-4	44.85% <100.00%> (-0.09%)	⬇️
shard-5	34.73% <100.00%> (-0.04%)	⬇️
shard-6	30.67% <100.00%> (+0.01%)	⬆️

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

Files with missing lines	Coverage Δ
src/github/backfill.ts	95.93% <100.00%> (+<0.01%)	⬆️

... and 2 files with indirect coverage changes

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-20 13:12:14 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This correctly fixes the described truncation bug: `files`/`reviews` connections now carry `pageInfo { hasNextPage endCursor }` and are walked independently with cursors up to a 10-page ceiling matching the REST path's bound, and a later-page failure keeps already-collected items rather than discarding them (mirroring `githubPaginatedList`'s partial-result semantics), while a page-1 failure still throws exactly as before so the caller's `.catch(() => undefined)` fallback contract is unchanged. The per-connection `hasNextPage` gating correctly stops re-requesting a connection once it's exhausted while the other keeps paginating, and the tests exercise both the multi-page case (101 files across two pages) and the no-extra-request case when both connections fit on page one via an assertion on `graphQlCalls`.

Nits — 5 non-blocking

• src/github/backfill.ts:4202 reuses the bare `404` from the pre-existing not-found throw; since it's now duplicated logic inside a loop, consider hoisting it to a named constant alongside `PR_DETAIL_GRAPHQL_MAX_PAGES`.
• The files/reviews per-page handling blocks (backfill.ts ~4207–4245) are near-identical push/pageInfo-update logic duplicated for each connection; consider extracting a small helper `advanceConnection(connectionNodes, pageInfo, cursor, hasNextPage, mapFn)` to cut the duplication and the nesting depth flagged by the external brief.
• The loop body nesting (conditional selections + try/catch + two near-identical per-connection blocks) is fairly deep; a small helper as above would also flatten this.
• Extract the shared 'push mapped nodes + advance cursor/hasNextPage' logic for files and reviews into one generic helper to reduce duplication and nesting in backfill.ts.
• Name the 404 literal (e.g. `const PR_NOT_FOUND_STATUS = 404`) for consistency with the new `PR_DETAIL_GRAPHQL_MAX_PAGES` constant added in this PR.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#7453
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: 1933 registered-repo PR(s), 1271 merged, 51 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	galuis116; Gittensor profile; 1933 PR(s), 51 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: significant

Linked issue satisfaction

Addressed
The diff adds pageInfo{hasNextPage,endCursor} to both files and reviews GraphQL connections, loops with an after-cursor bounded by a new PR_DETAIL_GRAPHQL_MAX_PAGES=10 constant mirroring PR_DETAIL_MAX_PAGES, preserves partial results on later-page failure while still throwing on page-1 failure, updates GitHubPullRequestDetailsResponse's type, and adds regression tests for both the >100-node two-pa

Review context

• Author: galuis116
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: JavaScript, Python, Dart, TypeScript, HTML, MDX, Rust, C++
• Official Gittensor activity: 1933 PR(s), 51 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Triage stale or unlinked PRs.

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.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 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 LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

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