fix: scope error-detection heuristics to error source in sanitizeUserFacingText#12052
Closed
skylarkoo7 wants to merge 2 commits intoopenclaw:mainfrom
Closed
fix: scope error-detection heuristics to error source in sanitizeUserFacingText#12052skylarkoo7 wants to merge 2 commits intoopenclaw:mainfrom
skylarkoo7 wants to merge 2 commits intoopenclaw:mainfrom
Conversation
…ror source
sanitizeUserFacingText() applies error-detection heuristics (HTTP status
matching, error-prefix detection, rate-limit / overload rewriting) to ALL
outbound text, including normal assistant responses. This causes false
positives when the assistant's reply happens to contain billing keywords
("credit balance", "402"), HTTP-like prefixes, or error-related phrases.
Add an optional `source` parameter ("assistant" | "error") so callers
can indicate the origin of the text. When source is "assistant", skip
the error-detection checks and only apply safe transforms (tag stripping,
duplicate block collapse). Existing callers without the parameter keep
the current behavior for backward compatibility.
Update all callers that process normal assistant content to pass
`{ source: "assistant" }`:
- normalize-reply.ts (outbound reply normalization)
- agent-runner-execution.ts (streaming text normalization)
- pi-embedded-utils.ts (assistant text extraction)
- sessions-helpers.ts (session text extraction)
Fixes openclaw#12022
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Add 8 tests verifying the { source: "assistant" } code path:
- billing keywords (credit balance, billing upgrade, insufficient credits)
are NOT rewritten
- HTTP status codes (500, 402) are NOT rewritten
- error-prefixed text ("Error: ...", "Failed: ...") is NOT rewritten
- raw JSON error payloads are NOT rewritten
- <final> tag stripping still works
- duplicate paragraph collapse still works
- normal multi-line assistant content passes through unchanged
skylarkoo7
force-pushed
the
fix/12022-billing-false-positive
branch
from
3648013 to
bb5cffa
Compare
Takhoffman
added a commit
that referenced
this pull request
Feb 10, 2026
Contributor
|
Fixed in #12988. This will go out in the next OpenClaw release. If you still see this after updating to the first release that includes #12988, please open a new issue with:
Link back here for context. |
thewilloftheshadow
force-pushed
the
main
branch
from
bfc1ccb to
f92900f
Compare
Contributor
|
Closing as superseded by the merged sanitize/error-context work:
This PR’s intent appears covered by those merged changes and current mainline tests. |
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
2 participants
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
sanitizeUserFacingText()applies error-detection heuristics (HTTP status matching, error-prefix detection, rate-limit rewriting) to all outbound text, including normal assistant responses. This causes false positives when the assistant's reply contains billing keywords ("credit balance","402"), HTTP-status-like prefixes, or error-related phrases — the entire response gets replaced with a generic error message.This PR adds an optional
sourceparameter ("assistant"|"error") so callers can indicate the origin of the text:"assistant"— skips the error-detection heuristics; only applies safe transforms (tag stripping, duplicate block collapse)"error"— applies the full error-detection and rewriting logic (current behavior)All callers that process normal assistant content now pass
{ source: "assistant" }:src/auto-reply/reply/normalize-reply.tssrc/auto-reply/reply/agent-runner-execution.tssrc/agents/pi-embedded-utils.tssrc/agents/tools/sessions-helpers.tsError-path callers (e.g.
formatAssistantErrorText) continue to use the default behavior and apply full error detection.Test plan
sanitizeUserFacingText,isBillingErrorMessage,formatAssistantErrorText, andclassifyFailoverReasonsuites)Fixes #12022
Greptile Overview
Greptile Summary
This PR scopes
sanitizeUserFacingText()’s error-detection/rewriting heuristics (HTTP status formatting, error-prefix detection, rate-limit/overload rewriting, billing keyword detection) to text that is known to originate from an error source.It introduces an optional
sourceoption ("assistant" | "error", defaulting to the previous behavior when omitted) and updates outbound/assistant-text call sites (normalize-reply, streaming normalization, transcript extraction) to pass{ source: "assistant" }so normal assistant replies don’t get replaced by generic error messages when they contain billing keywords (e.g. “credit balance”) or status-code-like text.Confidence Score: 4/5
{ source: "assistant" }behavior.source: "assistant"for normal assistant output while keeping backward-compatible defaults for error paths. The primary concern is that the test suite doesn’t exercise the new code path, so the intended prevention of false positives (billing keywords/status-like text) and preservation of safe transforms in assistant mode aren’t locked in by tests.source: "assistant"and optionallysource: "error")(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!