fix(claude): name the usage limit on retried turns too - #10546
fix(claude): name the usage limit on retried turns too#10546vitalyiegorov wants to merge 1 commit into
Conversation
The CLI re-sends the assistant rate_limit error on every limited turn but the rate_limit_event only when the state changes, so a retry while still limited fell back to the generic API error. Latch the assistant error like the sign-out case. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This narrowly scoped Claude adapter fix only improves the error message for retried usage-limited turns, preserving existing handling for authentication and other API errors. It includes targeted regression coverage and introduces no schema, deployment, security, billing, or configuration changes. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 10 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe Claude adapter now records ChangesClaude usage-limit reporting
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to Claude turns that report a rate-limit assistant error now consistently show the usage-limit guidance, while non-limit API failures retain the generic error message. No current merge-blocking risk remains. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Closes #10544.
What Changed
A Claude turn retried while the account is still limited now fails with the same sentence as the first limited turn, "Claude usage limit reached. Send the message again once the limit resets.", instead of falling back to "Claude gave up after repeated API errors."
The CLI sends
rate_limit_eventwithstatus: "rejected"only when the limit state changes, so #10321's latch saw it on the first turn and nothing on the retries. Those turns still carry anassistantmessage witherror: "rate_limit"(the same channel the sign-out latch already reads), so the adapter now records that too and the result names the limit. A boolean on the turn state rather than a sentinel in the rejected-window set, which recovery events add to and delete from by window id.Why
Three consecutive turns on one thread: the first said the limit, the next two said the provider gave up. Users read the second sentence as an outage and retry harder.
UI Changes
None beyond the sentence: the failed turn's banner and row are the ones #10321 introduced. Before, from the report in #10544:
Verification
vp test run apps/server/src/provider/Layers/ClaudeAdapter.test.ts— 120 tests pass, three new: a turn with only the assistantrate_limiterror names the limit in both the runtime error and the turn's error message; two consecutive turns in one session (first with therate_limit_event, second with only the assistant error) both name it; an assistantserver_errorstill yields the generic message. Reverting the condition fails exactly the two new positive cases.Checklist
Built with Claude Fable 5.1 in Claude Code, with an Opus subagent.
🤖 Generated with Claude Code
Note
Fix
ClaudeAdapterto name usage limit on retried turns with assistant-only rate-limit errorsAdds
rateLimitedAssistantMessageto the per-turn state in ClaudeAdapter.ts, set when an assistant SDK message reports arate_limiterror. The adapter now includes this flag alongsiderejectedRateLimitTypeswhen building the failure hint for result processing, so a failed turn is classified as a usage-limit error even when norate_limit_eventwas emitted (e.g. on a retry).server_error) keep the generic repeated-API-error message.Macroscope summarized 4a5f39d.
Summary by CodeRabbit