fix(api): clone request body per retry + classify timeouts (CLI-1D6)

[BYK]

Summary

Fixes CLI-1D6. The authenticated fetch retry loop reused the same (input, init) pair across attempts; any Request with a body (SDK path) or a ReadableStream init.body had its body consumed on attempt 1, so every retry after a timeout/5xx/401-refresh failed with TypeError: Request body already used. That bubbled up as the misleading ApiError: Unable to reach Sentry API. Cause: Request body already used — seen in the wild on a POST /autofix/ that timed out at 30s and couldn't retry.

Changes

All in src/lib/sentry-client.ts:

1. Body re-use fix — buildAttemptFactory yields a fresh (input, init) per attempt:

   • Request input → request.clone() per attempt (teed body stream).
   • ReadableStream body → materialized once to an ArrayBuffer (single-use shape).
   • Everything else (string / ArrayBuffer / TypedArray / Blob / FormData / URLSearchParams / none) passes through unchanged. fetch re-serializes these on every call, and re-serialization is required for FormData so the auto-negotiated Content-Type: multipart/form-data; boundary=... header is regenerated (used by sourcemap chunk upload).

2. Internal-timeout classification — Our per-request setTimeout-triggered abort now tags the caught error with a Symbol marker plus timeoutMs. handleFetchError surfaces a TimeoutError with "Request timed out after Ns." + actionable hint on the last attempt instead of the opaque "Network error" wrapper. User aborts (external signal) still propagate the original AbortError unchanged.

3. Per-endpoint timeout allowlist — ENDPOINT_TIMEOUT_OVERRIDES table. Seer /autofix/ POSTs trigger server-side root-cause analysis that can take ~2 minutes; they now get 120s. Default stays 30s. Adding new slow endpoints is a one-line change.

No caller changes needed — TimeoutError and ApiError both extend CliError, so the central error handler and existing instanceof ApiError branches in explain.ts / plan.ts keep working.

User-facing effect

Before: sentry issue explain <issue> against a Seer-slow backend produced ApiError: Unable to reach Sentry API. Cause: Request body already used after ~33s (30s timeout + 3s retry backoff that always failed).

After: the request either succeeds thanks to the 120s budget, or produces a clean TimeoutError: Request timed out after 120s. with a link to https://status.sentry.io.

Tests

New test/lib/sentry-client.test.ts — first test coverage this file has had. 8 tests:

• Retry-after-5xx reuses a string body.
• Retry-after-5xx reuses a Request body (SDK path, was CLI-1D6 root cause).
• Retry-after-5xx reuses a ReadableStream body via one-time materialization.
• Retry-after-5xx preserves the multipart Content-Type on a FormData body (regression from Cursor Bugbot finding on 78dea18).
• Internal timeout surfaces as TimeoutError after exhausting retries (uses __injectTimeoutOverrideForTests so the test doesn't wait 30s).
• External abort still propagates the original AbortError unchanged.
• resolveTimeoutMs returns 120_000 for /autofix/ paths (with/without trailing slash, with query params).
• resolveTimeoutMs returns 30_000 for non-overridden paths, including substring false-positives like /autofixation-report/.

Verification

• bunx tsc --noEmit — clean
• bun run lint — clean (one pre-existing warning in markdown.ts, unrelated)
• bun test test/lib/sentry-client.test.ts — 8/8 pass
• bun test test/lib/api/ test/commands/issue/ — broader suite green

Notes

• AGENTS.md churn from this branch is deliberately excluded — it belongs to separate lore-commits.
• The hot path (string body via apiRequestToRegion / rawApiRequest) is allocation-free on retry — no regressions for the typical call.
• Cursor Bugbot caught a real regression on the first iteration: materializing FormData stripped the multipart boundary. Fixed in f659777 by narrowing the materialization branch to just ReadableStream.

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://cli.sentry.dev/_preview/pr-829/
Built to branch gh-pages at 2026-04-23 11:29 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[github-actions]

Codecov Results 📊

✅ 138 passed | Total: 138 | Pass Rate: 100% | Execution Time: 0ms

📊 Comparison with Base Branch

Metric	Change
Total Tests	—
Passed Tests	—
Failed Tests	—
Skipped Tests	—

✨ No test changes detected

All tests are passing successfully.

✅ Patch coverage is 100.00%. Project has 1933 uncovered lines.
✅ Project coverage is 95.32%. Comparing base (base) to head (head).

Coverage diff

@@            Coverage Diff             @@
##          main       #PR       +/-##
==========================================
+ Coverage    95.27%    95.32%    +0.05%
==========================================
  Files          284       284         —
  Lines        41152     41297      +145
  Branches         0         0         —
==========================================
+ Hits         39206     39364      +158
- Misses        1946      1933       -13
- Partials         0         0         —

---

Generated by Codecov Action

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 78dea18. Configure here.}