fix: display rate limit errors correctly instead of as context overflow#8661
Open
dbottme wants to merge 3 commits intoopenclaw:mainfrom
Open
fix: display rate limit errors correctly instead of as context overflow#8661dbottme wants to merge 3 commits intoopenclaw:mainfrom
dbottme wants to merge 3 commits intoopenclaw:mainfrom
Conversation
Rate limit errors were being misreported as "Context overflow" because the context overflow check happened before the rate limit check. Both error types can contain "request" keywords which caused false positives. Now check for rate limit errors first, displaying a clear "Rate limit exceeded" message instead of the misleading context overflow message. Fixes openclaw#8047 Co-Authored-By: Claude Opus 4.5 <[email protected]>
Contributor
Additional Comments (1)
If Prompt To Fix With AIThis is a comment left during a code review.
Path: src/agents/pi-embedded-helpers/errors.ts
Line: 417:419
Comment:
`sanitizeUserFacingText` currently treats rate limit errors the same as overloaded errors and returns the overloaded message. With this PR, `formatAssistantErrorText` shows a specific rate limit message, but anything flowing through `sanitizeUserFacingText` will still misreport rate limits.
If `sanitizeUserFacingText` is used for user-visible errors in any path, consider splitting these cases so rate limits return the same "Rate limit exceeded…" copy (or reusing the formatter) instead of "temporarily overloaded".
How can I resolve this? If you propose a fix, please make it concise. |
Address review feedback: split rate limit handling from overloaded errors in sanitizeUserFacingText so users see "Rate limit exceeded" instead of "temporarily overloaded" for rate limit errors. Co-Authored-By: Claude Opus 4.5 <[email protected]>
Move rate limit and overloaded error checks before the raw API payload handling in sanitizeUserFacingText(). This ensures consistent user-facing messages regardless of whether the error arrives as a raw JSON payload, HTTP error text, or prefixed error string. Addresses review comment about rate limit errors being misreported as 'temporarily overloaded' when flowing through the raw API payload path.
bfc1ccb to
f92900f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Root cause
formatAssistantErrorText, the context overflow check happened before the rate limit checkChanges
Test plan
npm run check)vitest run src/agents/pi-embedded-helpers)Fixes #8047
🤖 Generated with Claude Code
Greptile Overview
Greptile Summary
This PR adjusts assistant error formatting so rate limit errors are detected and surfaced to users before the more general context overflow check, preventing rate-limit payloads that contain "request" wording from being mislabeled as context overflow. The change is localized to
src/agents/pi-embedded-helpers/errors.tsinformatAssistantErrorText.One inconsistency remains:
sanitizeUserFacingTextstill maps rate limit errors to the same message as overloaded errors, which may continue to misreport rate limits in any flow that uses that sanitizer rather thanformatAssistantErrorText.Confidence Score: 4/5
formatAssistantErrorTextand should not affect unrelated error cases. The main remaining concern is user-facing consistency: rate limit errors may still be mislabeled as overloaded in code paths usingsanitizeUserFacingText, which could partially negate the intended UX fix depending on call sites.