fix(github): keep public profile when repos JSON parse fails (#8891)

[andriypolanski]

Summary

• Closes fix(github): fetchPublicContributorProfile discards already-fetched user data on a JSON-parse failure, but not on an HTTP failure #8891
• Catches repos-list JSON parse failures separately from the user fetch so already-parsed profile fields survive with topLanguages: [] and source: "github" — matching the existing HTTP non-ok degrade path.
• Also stops pagination cleanly if a later repos page returns unparseable JSON (keeps page-1 languages).
• Adds regression coverage in test/unit/adapters.test.ts.

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
• npx vitest run test/unit/adapters.test.ts — 11 passed
• CI-scoped Codecov simulation: npx vitest run --changed=origin/main --coverage.all=false --coverage && npx diff-cover coverage/lcov.info --compare-branch=origin/main — 100% patch lines (13/13) and 100% patch branches (2/2) on src/github/public.ts
• npm run actionlint
• npm run typecheck
• npm run test:coverage
• 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:

Narrow src/github/public.ts fix; full test:ci left for the opener before push. Targeted adapters tests cover the new catch paths (first-page parse + later-page parse).

Notes for reviewers / gate

• No secrets, wallets, hotkeys, trust scores, or reward values.
• Does not touch site/, CNAME, **/lovable/**, or CHANGELOG.md.
• No UI Evidence (backend-only).

[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 90.58%. Comparing base (bc07e95) to head (1d88d5a).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8932      +/-   ##
==========================================
+ Coverage   90.56%   90.58%   +0.02%     
==========================================
  Files          96       97       +1     
  Lines       22490    22569      +79     
  Branches     3884     3907      +23     
==========================================
+ Hits        20367    20445      +78     
  Misses       1945     1945              
- Partials      178      179       +1     

Flag	Coverage Δ
backend	98.73% <100.00%> (?)

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

Files with missing lines	Coverage Δ
src/github/public.ts	98.73% <100.00%> (ø)

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-26 14:03:48 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR isolates the repos-list JSON parsing from the user fetch so a malformed repos body no longer discards an already-successful user lookup, mirroring the existing HTTP non-ok degrade path. The pagination loop is similarly wrapped so a later page's parse failure breaks the loop and keeps prior pages' data. The logic is correct as written, matches the stated intent, and the two new regression tests exercise both the first-page and later-page parse-failure paths against the real code (not fabricated states), consistent with a genuinely reachable failure mode (GitHub can return 200 with a truncated/invalid body).

Nits — 4 non-blocking

• src/github/public.ts: the inner try/catch around `reposResponse.json()` and the pagination try/catch duplicate the same pattern — consider a small helper like `async function parseReposOrEmpty(response)` to avoid repeating the try/catch shape twice.
• test/unit/adapters.test.ts: the two new tests both stub 'content-type': 'application/json' on an intentionally malformed body just to hit the catch — a brief comment noting this is deliberately malformed JSON (already present) is good, but consider also asserting `linkHeader`-driven pagination doesn't restart on retry, if retries exist elsewhere in the codebase (informational only, not required here).
• Consider extracting the repeated 'fetch + try/parse + on-failure reset' shape in src/github/public.ts:104-124 into a small shared helper to reduce duplication between the first page and subsequent pages.
• The PR description notes `npm run typecheck` and `npm run test:coverage` were skipped — worth confirming those pass before merge even though the scoped adapters test and CI both show green.

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	#8891
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: 199 registered-repo PR(s), 124 merged, 22 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	andriypolanski; Gittensor profile; 199 PR(s), 22 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Linked issue satisfaction

Addressed
The diff isolates the repos-list fetch/parse in its own try/catch so a JSON-parse failure now degrades to topLanguages: [] while preserving the already-parsed user fields and source: "github", matching the HTTP-failure path, and a new regression test in adapters.test.ts directly asserts this behavior.

Review context

• Author: andriypolanski
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, Rust, Cuda, JavaScript, Kotlin, MDX, Scala
• Official Gittensor activity: 199 PR(s), 22 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.

Decision record

• action: merge · clause: success
• config: 03a7f8b529a9 · pack: oss-anti-slop
• record: 343b4415b9ca (schema v2, head 1d88d5a)

_{🟩 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.