feat(miner): retry a transient 5xx around the CI and gate-verdict pollers

[real-venus]

Summary

A single brief 5xx from GitHub killed the entire poll loop: the CI and gate-verdict pollers' own attempt loop only re-polls while a conclusion is genuinely pending, never after a server error, so a 5xx response fell straight through to a thrown error and aborted the poll.

This adds a bounded fetchWithRetry wrapper (packages/gittensory-miner/lib/http-retry.js) around the pollers' single HTTP call:

• Retries only a transient 5xx response — exponential backoff (capped) with a max-attempts ceiling — distinct from the pollers' existing pending-retry loop.
• A 2xx/3xx/4xx response is returned immediately.
• After the last attempt a lingering 5xx is returned as-is, so the caller's own error handling still runs.
• A thrown network error is intentionally NOT retried — it propagates unchanged, preserving the pollers' existing failure-mode contract (test(miner-manage): regression coverage for the CI/gate polling backoff edge cases #4281, which deliberately bubbles network-level rejections to the caller).

Wired into ci-poller.js and gate-verdict-poller.js (one fetch call each). Pure control flow over injected fetchFn / sleepFn / backoffMs — no real network or timers.

Scope

• Narrow, one coherent change — a shared retry helper + two one-line poller wirings + tests
• In scope (packages/), no blockedPaths, no secrets/private terms
• Hand-authored .d.ts companion added
• Respects the adjacent test(miner-manage): regression coverage for the CI/gate polling backoff edge cases #4281 contract (thrown errors still propagate) rather than conflicting with it

Validation

• npm run typecheck
• npm run test:coverage (full unsharded suite)
• New unit test test/unit/miner-http-retry.test.ts: 2xx first-try, 4xx-no-retry, 5xx-then-success, 5xx-exhausted-returns-5xx, thrown-error-propagates-immediately (no retry), maxAttempts=1, built-in sleep/backoff defaults, backoff sequence + fractional-maxAttempts flooring — 100% coverage
• test/unit/miner-ci-poller.test.ts: a transient 5xx mid-poll is retried and the poll completes (Add retry/backoff to the CI and gate-verdict pollers #4829 acceptance)
• The existing #4281 failure-mode tests pass unchanged (thrown rejections still propagate immediately)

Safety

• Read-only: wraps existing GET calls; no writes, no new endpoints
• Bounded attempts + capped backoff; maxAttempts floored-then-checked so a fractional value can't disable retries into a 0-attempt loop
• No secrets, tokens, wallets, trust scores, or reward values in code, tests, or this description

Closes #4829

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

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5420   +/-   ##
=======================================
  Coverage   94.45%   94.45%           
=======================================
  Files         553      554    +1     
  Lines       44357    44371   +14     
  Branches    14659    14659           
=======================================
+ Hits        41898    41912   +14     
  Misses       1784     1784           
  Partials      675      675           

Flag	Coverage Δ
shard-1	43.90% <81.25%> (-0.23%)	⬇️
shard-2	34.74% <0.00%> (+0.13%)	⬆️
shard-3	31.57% <0.00%> (-0.01%)	⬇️
shard-4	31.23% <87.50%> (-0.19%)	⬇️
shard-5	32.93% <93.75%> (-0.37%)	⬇️
shard-6	43.95% <93.75%> (+0.54%)	⬆️

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

Files with missing lines	Coverage Δ
packages/gittensory-miner/lib/ci-poller.js	95.87% <100.00%> (ø)
...ckages/gittensory-miner/lib/gate-verdict-poller.js	96.96% <100.00%> (ø)
packages/gittensory-miner/lib/http-retry.js	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.

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-12 18:17:38 UTC}

6 files · 2 AI reviewers · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
Adds a bounded `fetchWithRetry` wrapper (packages/gittensory-miner/lib/http-retry.js) that retries a transient 5xx response with capped exponential backoff, distinct from the pollers' pre-existing pending-retry loop, and wires it into ci-poller.js and gate-verdict-poller.js. The control flow is correct: a thrown network error still propagates unchanged (preserving the #4281 contract, confirmed by the untouched miner-ci-poller-failure-modes.test.ts), 2xx/3xx/4xx return immediately, and a lingering 5xx after maxAttempts is returned as-is so the caller's existing error handling still fires. Tests are thorough (backoff sequencing, exhausted-5xx, thrown-error-no-retry, fractional maxAttempts flooring) and the PR is explicitly tied to issue #4829.

Nits — 5 non-blocking

• packages/gittensory-miner/lib/http-retry.js:49 — gate-verdict-poller.js and ci-poller.js both reuse the poller's own `sleepFn` for the inner 5xx-retry backoff, so in production the inner retry's fixed 500ms/1000ms/2000ms schedule runs through the same clock as the outer pending-poll backoff (whose interval is configurable via minIntervalMs/maxIntervalMs) — worth a one-line comment clarifying these two backoff schedules are independent by design, since a future reader could assume they're coupled.
• packages/gittensory-miner/lib/http-retry.js:11 — DEFAULT_BASE_BACKOFF_MS (500) is a bare literal; naming it doesn't change behavior but the external brief's suggestion to extract intent is reasonable given the file already extracts DEFAULT_MAX_ATTEMPTS and MAX_BACKOFF_MS as constants.
• gate-verdict-poller.js doesn't pass a `maxAttempts` override into fetchWithRetry, so it always gets the http-retry default of 3 regardless of how many attempts the outer poll has left — fine today but worth confirming that's intended if maxAttempts is ever tuned down to 1 for a fast-fail caller.
• Consider a short comment at the fetchWithRetry call sites noting that the inner 5xx-retry schedule is independent of the outer poll's minIntervalMs/maxIntervalMs, to preempt confusion for the next contributor touching backoff tuning.
• nit: packages/gittensory-miner/lib/ci-poller.js:87 and packages/gittensory-miner/lib/gate-verdict-poller.js:90 say the wrapper retries transient network errors, but packages/gittensory-miner/lib/http-retry.js:44 intentionally lets thrown network errors propagate without retrying; change the comments to say only 5xx responses are retried.

Signal	Result	Evidence
Code review	✅ No blockers	2 reviewers, synthesized
Linked issue	✅ Linked	#4829
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: 103 registered-repo PR(s), 54 merged, 12 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	real-venus; Gittensor profile; 103 PR(s), 12 issue(s).
Gate result	✅ Passing	No configured blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence. LLM value judgment: moderate — The change closes a real, previously-demonstrated gap (a single transient 5xx aborting the whole poll) with a narrow, well-tested, non-invasive wrapper that respects the existing #4281 failure-mode contract.

Linked issue satisfaction

Addressed
The PR adds a bounded retry/backoff wrapper (fetchWithRetry) distinct from the pollers' existing pending-retry loop, wires it into both the CI and gate-verdict pollers' HTTP calls, and includes a test demonstrating a transient 5xx mid-poll is retried and the poll completes successfully, matching the stated acceptance criterion.

Review context

• Author: real-venus
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 103 PR(s), 12 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.

[BETA] Chat with Gittensory

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

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

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

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

[loopover-orb]

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