fix: Altimate Base 413 HTML body and missing header timeout - #1256
fix: Altimate Base 413 HTML body and missing header timeout#1256anandgupta42 wants to merge 1 commit into
Conversation
- `describeRequestTooLarge` now takes `{ status, body }` instead of a bare
body string, and returns the friendly "request too large" message on any
HTTP `413` even when the body is unparseable (nginx's raw HTML edge
rejection in production, not LiteLLM's JSON shape). A 413 whose body still
parses to the known `request_too_large` JSON shape keeps the more specific
byte-count message; any other 413 shape or non-413 status is unchanged
(`undefined`).
- Updated the sole caller in `provider/error.ts` to thread `statusCode`
through, and updated every test call site to the new object signature.
- Added `headerTimeout: OPENAI_HEADER_TIMEOUT_DEFAULT` to the `altimate-free`
provider loader's options in `provider/provider.ts`, matching the existing
`openai` loader default, so a hung gateway response can no longer hang the
CLI forever.
- Added unit tests covering the HTML/empty-body 413 fallback, the
still-specific JSON-shape 413 case, a non-413 HTML body (no fallback), and
the `altimate-free` provider's `headerTimeout`.
Closes #1255
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.
Tip: disable this comment in your organization's Code Review settings.
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_ab8b4145-ae26-44eb-8057-a4fca3a83b1f) |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
full receipts (1 session)
builder ·
|
|
👋 This PR was automatically closed by our quality checks. Common reasons:
If you believe this was a mistake, please open an issue explaining your intended contribution and a maintainer will help you. |
2 similar comments
|
👋 This PR was automatically closed by our quality checks. Common reasons:
If you believe this was a mistake, please open an issue explaining your intended contribution and a maintainer will help you. |
|
👋 This PR was automatically closed by our quality checks. Common reasons:
If you believe this was a mistake, please open an issue explaining your intended contribution and a maintainer will help you. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (7)
Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review. 📝 WalkthroughWalkthroughAltimate Base now returns a friendly request-size message for HTTP 413 responses with JSON, HTML, empty, or malformed bodies. The provider also applies a 10-second header timeout. ChangesAltimate Base provider behavior
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to Altimate Base users now receive clear request-size guidance for all 413 response formats, and stalled gateway header responses time out after 10 seconds. Focused error-handling and provider configuration coverage supports merge readiness. Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
👋 This PR was automatically closed by our quality checks. Common reasons:
If you believe this was a mistake, please open an issue explaining your intended contribution and a maintainer will help you. |
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (7 files)
Reviewed by deepseek-v4-pro · Input: 40.8K · Output: 13.1K · Cached: 397.4K Review guidance: REVIEW.md from base branch |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
1 participant
Issue for this PR
Closes #1255
Type of change
What does this PR do?
Fixes two client-side Altimate Base bugs found by live-prod E2E of the
v0.11.0-beta.2release.Bug 1 — 413 oversize error showed a generic message instead of the friendly one.
FreeTier.describeRequestTooLargeinpackages/opencode/src/altimate/free/client.tsdidJSON.parse(body)in a try/catch that returnedundefinedon a parse failure. In production, oversized requests are rejected by the gateway's edge proxy with a raw HTML error page (not a JSON body), so the parse always throws for that case, the function always returnedundefined, and the user saw a generic fallback error instead of the friendly "your request is too large — start a new session or shorten it" message.Fix:
describeRequestTooLargenow takes{ status, body }instead of a bare body string. Its logic is now:request_too_largeshape, keep the existing specific message (with the KB byte-count detail when present).undefined— unchanged behavior, no false positives even though the status is 413.413, return the same friendly fallback message the JSON path produces.undefinedfor an unparseable body — unchanged.The sole caller in
packages/opencode/src/provider/error.tsalready knew the status was 413 before calling (it gates oninput.error.statusCode === 413); it now threadsinput.error.statusCodethrough explicitly so the function itself can make the same decision without relying on caller-side control flow alone. All existing test call sites were updated to the new object signature.Bug 2 — Altimate Base provider had no client-side header timeout.
The
"altimate-free"loader inpackages/opencode/src/provider/provider.tsreturnedoptions: { baseURL, apiKey, fetch }with noheaderTimeout, unlike theopenailoader in the same file, which setsheaderTimeout: OPENAI_HEADER_TIMEOUT_DEFAULT. If the gateway hung before sending response headers, a request through Altimate Base had no client-side timeout and could hang the CLI indefinitely.Fix: added
headerTimeout: OPENAI_HEADER_TIMEOUT_DEFAULTto thealtimate-freeloader's options, matching theopenailoader's existing default.How did you verify your code works?
bun run typecheck(root, via turbo) — passes across all 15 packages.test/altimate/altimate-base-rate-limit-messages.test.ts: a raw-HTML 413 body returns the friendly fallback; an empty/absent-body 413 returns the same fallback; a 413 with the known JSON shape still returns the specific byte-count message (not the fallback); a non-413 status with an HTML body still returnsundefined; a 413 with valid-but-unrelated JSON still returnsundefined.test/provider/error.test.tsexercising the fullProviderError.parseAPICallErrorpath with a 413 + raw HTML body, asserting the friendly message comes out end-to-end.test/provider/provider.test.tsto assertoptions.headerTimeoutis set to the same default theopenailoader uses.describeRequestTooLargecall site (production and test) to the new{ status, body }signature.test/altimate/altimate-base-rate-limit-messages.test.ts,test/altimate/altimate-base-error-surfacing.test.ts,test/provider/error.test.ts,test/provider/provider.test.ts,test/provider/header-timeout.test.ts, and the fulltest/altimate/directory — all green (5104 pass / 0 fail across the altimate suite; 150 pass / 0 fail for the four directly-targeted files).bun run script/upstream/analyze.ts --markers --base origin/main --strict— reports no upstream-shared files were touched (client.tsandprovider.tsare altimate-owned, not upstream-shared), so no marker violations; new hunks are still wrapped inaltimate_changecomments for consistency with the surrounding code.Not verified: the 413 fix is verified by unit test (a synthetic raw-HTML body) and by the
parseAPICallErrorintegration test, but has not been re-run against a live oversized request through the real production nginx edge — that would require reproducing a >1MiB request against the live gateway, which wasn't done as part of this fix.Screenshots / recordings
N/A — no UI change.
Checklist
Note
Low Risk
Localized Altimate Base error mapping and provider timeout defaults; behavior is well covered by unit/integration tests with no auth or data-model changes.
Overview
Fixes two Altimate Base client bugs: oversized-request errors and hung gateway calls.
413 / request too large:
describeRequestTooLargenow takes{ status, body }instead of a raw body string. When the response is 413 with HTML or empty/unparseable bodies (production nginx edge rejection), it returns the same friendly Altimate Base message instead ofundefined, soparseAPICallErrorno longer falls through to genericcontext_overflow. JSONrequest_too_largeresponses still get byte-count detail when available; unrelated 413 JSON shapes are left unchanged.Header timeout: The
altimate-freeprovider loader setsheaderTimeout: OPENAI_HEADER_TIMEOUT_DEFAULT(10s), matching OpenAI so a stalled gateway cannot hang the CLI indefinitely.Tests cover nginx HTML 413 end-to-end, edge cases for the new signature, and provider
headerTimeoutassertion.Reviewed by Cursor Bugbot for commit eeccaa9. Bugbot is set up for automated code reviews on this repo. Configure here.
Summary by cubic
Fixes two Altimate Base client-side bugs found in live-prod E2E: oversized requests now show the friendly "request too large" message even when the gateway rejects with raw HTML, and a hung gateway response no longer hangs the CLI. Closes #1255.
Bug Fixes
describeRequestTooLargenow takes{ status, body }and returns the friendly message on any 413, even when the body doesn't parse as JSON.request_too_largeshape still returnsundefined, as does any non-413 status.altimate-freeprovider loader now setsheaderTimeout, matching theopenailoader's default.Written for commit eeccaa9. Summary will update on new commits.
Summary by CodeRabbit
Bug Fixes
Tests