fix(codex): show neutral wording for exhausted HTTP 429 retries - #26532

Approvability

Verdict: Approved at ea55947

Macroscope's review found this PR approvable — Exhausted HTTP 429 retries receive neutral provider-rate-limit wording across web and mobile, with the provider’s explanation visible in work logs. Retry and recovery behavior remain unchanged.

^{You can add or adjust custom eligibility rules. Learn more.}

No actionable comments were generated in the recent review.

Merge Risk: Minimal · up to fdc03

The change updates wording for exhausted HTTP 429 retries across the server, web and mobile, and no concrete defect is evident in the supplied material. Explicit rate-limit errors still use the old wording, which is a known follow-up and does not block merging.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: exhausted Codex HTTP 429 retries now show neutral wording instead of the usage-limit text. It is a conventional commit title that matches the changeset, which adds a s…
Description check		The description follows the template sections: Problem, Change, Scope, and Verification. It names the issue (#24885), explains the change, gives the scope rationale, and reports detailed test commands…
Linked Issues check		Directly linked issue #24885 asks that an ambiguous Codex HTTP 429 not be presented as proof of exhausted usage allowance. It also asks that provider details be preserved, and that manual retry remain…
Out of Scope Changes check		All changed files apply the same title decision or the same warning-row message display. The changes cover the server failure item, the shared helper, the web timeline, banner, sidebar, notification, …

Full details: Title check

Explanation

The title names the main change: exhausted Codex HTTP 429 retries now show neutral wording instead of the usage-limit text. It is a conventional commit title that matches the changeset, which adds a shared providerFailureTitle helper and applies it across server, web, and mobile.

Full details: Description check

Explanation

The description follows the template sections: Problem, Change, Scope, and Verification. It names the issue (#24885), explains the change, gives the scope rationale, and reports detailed test commands and results. It also states limitations, including no UI screenshots, which the template requires for UI changes. The missing screenshots are a gap against the template, but the other required sections are substantively complete.

Full details: Linked Issues check

Explanation

Directly linked issue #24885 asks that an ambiguous Codex HTTP 429 not be presented as proof of exhausted usage allowance. It also asks that provider details be preserved, and that manual retry remain available without an invented reset time.

The reproduced failure is responseTooManyFailedAttempts with exceeded retry limit, last status: 429 Too Many Requests. The shared helper providerFailureTitle in packages/shared/src/orchestrationV2ThreadError.ts maps this case to Provider rate limit (HTTP 429). Explicit usageLimitExceeded keeps Usage limit reached. packages/provider-core/src/server/failure.ts applies the title to terminal and failed-retry items and keeps the failure object. The web (session-logic.ts, TimelineWorkEntryRow.tsx, UsageLimitRecoveryBanner.tsx, SidebarThreadRow.tsx, ThreadNotificationCoordinator.tsx) and mobile (threadActivity.ts, thread-work-log.tsx, UsageLimitRecoveryCard.tsx) projections use the same helper. The missing-reset text is now No reset time reported; retry manually. Warning rows show the retained provider message.

Tests in failure.test.ts, session-logic.test.ts, threadActivity.test.ts, and UsageLimitRecoveryBanner.test.tsx cover the ambiguous 429 case, the explicit quota case, retained details, and legacy titles. Manual Resume, reset timestamps, and retry policy are documented as unchanged.

Residual limits: the upstream capacity text (turn_rate_limit_exceeded) is not in the stored failure, so T3 cannot restore that explanation. The issue acknowledges that Codex may discard it. Explicit rateLimitExceeded TPM failures still show Usage limit reached. That case is a separate reported path and is deferred by the PR. Browser and UI verification was not performed, so the rendered wording is supported by unit tests and not by screenshots.

Full details: Out of Scope Changes check

Explanation

All changed files apply the same title decision or the same warning-row message display. The changes cover the server failure item, the shared helper, the web timeline, banner, sidebar, notification, and session logic, and the mobile feed, timeline, and recovery card. Each change supports the correction of the usage-limit explanation described in #24885.

The PR does not add a recovery workflow, automatic retry, wire-contract change, or serverOverloaded handling. The PR states that adapter classification, Limited state, manual Resume, reset timestamps, retry policy, and provider/model selection are unchanged. Test files support the changed behavior. No unrelated change appears in the reviewed summary. The PR also states that no historical backfill is included, and no such backfill appears in the changed files.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 0d51d5b
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: ea61b748-6f2a-4803-87a8-f20b16ec4df8

Commits

Reviewing files that changed from the base of the PR and between 9d0b12f and fdc03e3.

Files selected for processing: 11

• apps/mobile/src/features/threads/UsageLimitRecoveryCard.tsx
• apps/mobile/src/features/threads/thread-work-log.tsx
• apps/mobile/src/lib/threadActivity.test.ts
• apps/mobile/src/lib/threadActivity.ts
• apps/web/src/components/ThreadNotificationCoordinator.tsx
• apps/web/src/components/chat/TimelineWorkEntryRow.tsx
• apps/web/src/components/chat/UsageLimitRecoveryBanner.tsx
• apps/web/src/components/sidebar/SidebarThreadRow.tsx
• apps/web/src/session-logic.ts
• packages/provider-core/src/server/failure.test.ts
• packages/provider-core/src/server/failure.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

Takeover update

merged current main into the branch at 9d0b12f855 (merge commit, no rebase). the change's intent and size are unchanged.

• conflicts were in UsageLimitRecoveryBanner.tsx, its test, and ChatView.tsx. main added a ChatGPT-branded notice and an errorCode prop for the same data this pr passed as failureCode.
• resolution: kept main's errorCode name and its ChatGPT branch (partner-guideline copy) unchanged. the generic branch now uses providerFailureTitle("usage_limit", errorCode), so exhausted responseTooManyFailedAttempts retries show "Provider rate limit (HTTP 429)". the reset fallback uses this pr's "No reset time reported; retry manually".
• vp run check:changed passes on a blacksmith testbox: format, lint, knip, typecheck (34 packages), tests (9 files), react compiler.

Not changed

• explicit rateLimitExceeded (the TPM case reported above) still shows "Usage limit reached". covering it would widen this pr, so it is left for a follow-up.
• the exhausted-429 ui state is still unverified in a real app. no real 429 was available, same as the earlier note.

Earlier verification (gpt-6.1-sol, at ea55947ac8)

partial verification only. the changed http 429 behavior is unverified.

• started github/main (32ecd71726) and then the pr with isolated data, one dev server at a time, repo playwright and /usr/bin/google-chrome.
• created projects pointing at real git checkouts, selected codex gpt-6.1-sol, submitted the same prompt, and saw verification baseline ok. on both revisions. main needed a reload to display its already-persisted answer.
• on the pr, ran a real codex terminal command (sleep 60), clicked stop, saw Run interrupted · Stopped by user, then saw follow-up after stop ok. in the same thread. persisted run statuses were completed, interrupted, completed.
• the four changed regression files passed through blacksmith: 104 tests in 4 files.

short provider/server transcript

main, normal provider turn (this does not reproduce the 429 bug):

pr, matching prompt and answer:

shortened capture of the real command, stop and follow-up; sampled frames, not timing evidence:

not verified then: the original bug on main and the exhausted-429 wording on the pr (the real proxy returned successes, and no mocks or injected errors were used), the limited-state banner, warning row, sidebar tooltip, notification, manual resume, reset scheduling, recovered-retry presentation, desktop electron, native mobile, relay/tunnel, and other operating systems.

Verified an additional case on Windows with T3 0.1.8-nightly.20261104.4165, using Codex through ChatGPT sign-in on a Pro subscription. The user reports 99% of their weekly allowance remaining; I did not independently verify that percentage.

The captured terminal turn/completed error is explicitly a throughput rejection:

codexErrorInfo: rateLimitExceeded
Rate limit reached for gpt-6.1-sol ... on tokens per min (TPM):
Limit 1000000, Used 732209, Requested 360332.
Please try again in 5.552s.

I fetched this PR at ea55947ac8e0f3948ff7ccd400e73b1adc16c87c and executed its exact codexUsageLimitError and providerFailureTitle function bodies against a captured terminal TPM error. It still becomes class: usage_limit with the title Usage limit reached. The added failure.test.ts table explicitly expects that title for rateLimitExceeded; only responseTooManyFailedAttempts receives the neutral rate-limit title.

Could this wording fix also cover explicit rateLimitExceeded? In this incident the provider retains the specific TPM explanation, so the headline can distinguish rate throttling from subscription allowance exhaustion without guessing. Showing the retained message in the timeline is helpful, but the recovery banner and other shared-title consumers would still use the misleading headline.

Verification was limited to executing the PR's classifier/title logic with the captured error and inspecting its web/mobile consumer call sites. No browser test, full adapter replay, or live throttling reproduction was performed. No retry-policy change is requested here.

Posted by Codex (GPT-6.1 Sol) through T3 Code on behalf of the user.