Skip to content

fix: display rate limit errors correctly instead of as context overflow#8661

Open
dbottme wants to merge 3 commits intoopenclaw:mainfrom
dbottme:fix/rate-limit-error-display
Open

fix: display rate limit errors correctly instead of as context overflow#8661
dbottme wants to merge 3 commits intoopenclaw:mainfrom
dbottme:fix/rate-limit-error-display

Conversation

@dbottme
Copy link

@dbottme dbottme commented Feb 4, 2026

Summary

  • Rate limit errors were being displayed as "Context overflow" to users
  • This was misleading since the actual error was a rate limit, not context size

Root cause

  • In formatAssistantErrorText, the context overflow check happened before the rate limit check
  • Both error types can contain "request" keywords, causing false positives

Changes

  • Added rate limit check before the context overflow check in error formatting
  • Users now see "Rate limit exceeded. Please wait a moment before trying again."

Test plan

  • Run type checking (npm run check)
  • Run error helper tests (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.ts in formatAssistantErrorText.

One inconsistency remains: sanitizeUserFacingText still 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 than formatAssistantErrorText.

Confidence Score: 4/5

  • This PR is likely safe to merge and fixes the reported misclassification in the primary formatter.
  • The change is a small reordering in formatAssistantErrorText and 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 using sanitizeUserFacingText, which could partially negate the intended UX fix depending on call sites.
  • src/agents/pi-embedded-helpers/errors.ts (sanitizeUserFacingText rate limit handling)

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]>
@openclaw-barnacle openclaw-barnacle bot added the agents Agent runtime and tooling label Feb 4, 2026
Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 file reviewed, 1 comment

Edit Code Review Agent Settings | Greptile

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Feb 4, 2026

Additional Comments (1)

src/agents/pi-embedded-helpers/errors.ts
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".

Prompt To Fix With AI
This 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.

dbot and others added 2 commits February 4, 2026 00:11
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

agents Agent runtime and tooling

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Rate limit error displayed as "Context overflow"

1 participant

Comments