fix(scripts): bound outbound fetches in unattended release/observability scripts (#7014)

[jeffrey701]

Summary

Three unattended, CI-workflow-driven scripts made outbound fetches with no per-request timeout, so a single hung connection could block the job past its intended deadline (or indefinitely) — unlike sibling scripts in the same release/observability-automation family (e.g. smoke-production.mjs's fetchWithTimeout) that already guard against exactly this.

• scripts/check-mcp-release-due.mjs's githubRequest() (runs via .github/workflows/mcp-release-watch.yml) — added an AbortSignal.timeout to its api.github.com fetch.
• scripts/smoke-observability-traces.mjs — both the trace-push fetch and each polling fetch in the generated smoke script now carry a per-call AbortSignal.timeout(OBSERVABILITY_SMOKE_TIMEOUT_MS). Previously only the between-iterations deadline was checked, so a single hung request could still block past it.
• scripts/smoke-observability-metrics.mjs — the same fix for all three of its fetches (collector push, collector poll, and the app's own /metrics probe).

Why

These jobs run without a human watching. A dead/slow endpoint on any of these fetches would hang the CI job rather than fail fast, which is the exact failure mode the per-request timeout in the sibling scripts already prevents.

Validation

• Both the outer scripts and the generated inner smoke-script code node --check clean.
• The existing script tests (mcp-release, mcp-release-candidate, selfhost-observability-config, observability-ci, smoke-production-versions, smoke-selfhost-script) pass unchanged.
• New test/unit/observability-release-fetch-timeout.test.ts asserts every fetch( in these scripts is now paired with an AbortSignal.timeout( — one guard per outbound call, so an un-bounded fetch can't silently regress back in.

Closes #7014

[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 93.74%. Comparing base (b153047) to head (0a09a12).
⚠️ Report is 21 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7044      +/-   ##
==========================================
+ Coverage   89.37%   93.74%   +4.37%     
==========================================
  Files         692      692              
  Lines       68748    68706      -42     
  Branches    18769    18760       -9     
==========================================
+ Hits        61442    64409    +2967     
+ Misses       5545     3302    -2243     
+ Partials     1761      995     -766     

Flag	Coverage Δ
shard-1	43.79% <ø> (-0.01%)	⬇️
shard-2	36.85% <ø> (+<0.01%)	⬆️
shard-3	33.13% <ø> (?)
shard-4	34.48% <ø> (+0.57%)	⬆️
shard-5	32.27% <ø> (+0.03%)	⬆️
shard-6	45.75% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 103 files with indirect coverage changes

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-17 19:42:53 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR adds a per-request AbortSignal.timeout to previously-unbounded fetch calls in three unattended CI scripts (check-mcp-release-due.mjs, smoke-observability-traces.mjs, smoke-observability-metrics.mjs), matching the fetchWithTimeout pattern already used in smoke-production.mjs. The fix is correctly scoped and traceable to the real source: each of the six affected fetch call sites now has its own signal, closing the gap where only the outer while-loop deadline was checked but a single hung request inside the loop could still block indefinitely. The new structural test verifies fetch/AbortSignal.timeout call-count parity per file, which is a reasonable regression guard given these scripts run against live containers/GitHub and can't be easily unit-tested end-to-end.

Nits — 5 non-blocking

• The structural regex-based test (test/unit/observability-release-fetch-timeout.test.ts) only checks that fetch() and AbortSignal.timeout() counts match, not that each timeout is actually wired into the correct fetch's options object — a future refactor could shuffle the association while keeping counts equal and still pass.
• The hardcoded otel-collector/tempo hostnames flagged in the external brief predate this diff and aren't part of the timeout fix, so they're out of scope here but worth a follow-up issue if not already tracked.
• GITHUB_REQUEST_TIMEOUT_MS (30s) and OBSERVABILITY_SMOKE_TIMEOUT_MS (default 30s, reused per-fetch) mean the total worst-case wall time across sequential fetches in a single poll iteration is now up to 2-3x the configured timeout instead of a single bound — acceptable but worth noting in a comment for future maintainers tuning CI timeouts.
• Consider adding one assertion in the test that greps for the specific fetch-call + AbortSignal.timeout pairing on the same statement/template literal (e.g. a regex spanning `fetch(...signal: AbortSignal.timeout`) to catch a shuffled association, not just aggregate counts.
• In check-mcp-release-due.mjs, the 30_000ms constant is a plain number; consider allowing an env override (e.g. GITHUB_REQUEST_TIMEOUT_MS) for parity with the observability scripts' OBSERVABILITY_SMOKE_TIMEOUT_MS env knob, though this isn't required for the fix.

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	#7014
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: 145 registered-repo PR(s), 70 merged, 32 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jeffrey701; Gittensor profile; 145 PR(s), 32 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Partially addressed
The diff adds AbortSignal.timeout guards to all fetches in check-mcp-release-due.mjs, smoke-observability-traces.mjs, and smoke-observability-metrics.mjs, matching the sibling fetchWithTimeout precedent and satisfying the first three deliverables. However, the added test only structurally asserts that fetch calls are paired with AbortSignal.timeout via regex counting; it does not simulate a never-

Review context

• Author: jeffrey701
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript, Clojure, JavaScript, Rust
• Official Gittensor activity: 145 PR(s), 32 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.