fix(discovery-index): record the declared cache-lookup and github-request-outcome metrics

[shin-core]

What

Wires up two metrics that packages/discovery-index already declares in DEFAULT_METRIC_META but never actually records, so discovery_index_cache_lookups_total and discovery_index_github_requests_total stay at zero on a live instance.

Closes #7432

Details

• discovery-query.ts — at both TtlCache.getOrCompute call sites (the result cache in runDiscoveryQuery, the policy cache in resolveRepoAiPolicy), record discovery_index_cache_lookups_total { cache: "result"|"policy", outcome: "hit"|"miss" }. "miss" = the compute callback actually ran; "hit" = it didn't. Detected with a missed flag set as the first line of the compute callback, then incr(...) after the call resolves.
• github-client.ts — in fetchWithRetry, record discovery_index_github_requests_total { outcome: "ok"|"retried"|"failed" }: one "retried" immediately before each sleepFn (per attempt beyond the first), and one "ok"/"failed" (response.ok ? "ok" : "failed") at the return — the retried increments are in addition to, never instead of, the terminal ok/failed. Adds the file's first import { incr } from "./metrics.js".

No retry/return logic changed, and DEFAULT_METRIC_META / the metric contract is untouched — this is purely wiring the missing incr() calls.

Validation

• Added tests to the existing test/unit/discovery-index/{discovery-query,github-client}.test.ts: cache miss-then-hit for both the result and policy caches; a single 200 → one ok; a 500-then-200 → one retried + one ok; an all-500 max-attempts exhaustion → retried-per-extra-attempt + one failed. Counters are reset per test.
• Both suites pass (45 tests). Coverage on the two changed files is 100% branch on every added line. git diff --check clean; the discovery-index contract test still passes (18/18).

[superagent-security]

🚨 Contributor flagged. Click here for more info: Superagent Dashboard

[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.40%. Comparing base (3ee9e4e) to head (7d4fb14).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7500      +/-   ##
==========================================
- Coverage   91.41%   91.40%   -0.02%     
==========================================
  Files         717      717              
  Lines       73036    73047      +11     
  Branches    21635    21638       +3     
==========================================
  Hits        66766    66766              
- Misses       5227     5234       +7     
- Partials     1043     1047       +4     

Flag	Coverage Δ
shard-1	31.89% <0.00%> (-0.05%)	⬇️
shard-2	36.01% <71.42%> (+0.03%)	⬆️
shard-3	31.47% <28.57%> (+0.02%)	⬆️
shard-4	43.91% <57.14%> (-0.02%)	⬇️
shard-5	37.05% <0.00%> (-0.01%)	⬇️
shard-6	35.83% <0.00%> (-0.10%)	⬇️

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

Files with missing lines	Coverage Δ
packages/discovery-index/src/discovery-query.ts	100.00% <100.00%> (ø)
packages/discovery-index/src/github-client.ts	100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-20 13:57:17 UTC}

4 files · 1 AI reviewer · no blockers · CI green · unstable

⏸️ Suggested Action - Manual Review

Review summary
This wires up two previously-declared-but-unrecorded counters: cache lookup outcomes in discovery-query.ts (via a `missed` flag set inside the `getOrCompute` compute callback, then `incr()` after the await resolves) and GitHub request outcomes in github-client.ts's `fetchWithRetry` (a `retried` increment before each backoff sleep, and a terminal `ok`/`failed` increment at return). Both wiring sites are traced correctly: the `missed` flag can only flip to `true` if the compute callback actually runs, which happens only on a real cache miss, and the retry loop's `incr` calls are additive to, not replacing, the terminal outcome exactly as described. Tests exercise the real code paths (miss-then-hit, single-200, 500-then-200, and max-attempts exhaustion) using the actual `counterValue`/`resetMetrics` exports rather than fabricated payloads, which is solid coverage for pure wiring.

Nits — 4 non-blocking

• discovery-query.ts:97-108 and :176-180 duplicate the same `let missed = false; ... incr(...)` pattern twice — worth a tiny shared helper if a third cache is ever added, though at two call sites it's not worth it yet.
• github-client.ts's `fetchWithRetry` is also used internally by `fetchRepoFile`, so the same `discovery_index_github_requests_total` counter aggregates issue-list, search, and file-content requests together — confirm that's the intended granularity per the metric's declared labels in metrics.ts (not shown in this diff).
• Consider a one-line comment at the `missed` flag declarations noting that it's only ever set inside the compute callback, to make the hit/miss inference obvious to a future reader without re-deriving it from `TtlCache.getOrCompute`'s semantics.
• No functional changes needed — this is clean, narrowly-scoped wiring with matching tests.

Flagged checks (non-blocking)

• Contributor trust — Contributor flagged for review

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	#7432
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: 74 registered-repo PR(s), 45 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	shin-core; Gittensor profile; 74 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: shin-core
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript, JavaScript, Solidity, Dart, Python, CSS, PHP, Rust
• Official Gittensor activity: 74 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

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.