fix: prevent sanitizeUserFacingText false-positives on assistant prose#12702
fix: prevent sanitizeUserFacingText false-positives on assistant prose#12702zerone0x wants to merge 1 commit intoopenclaw:mainfrom
Conversation
…nt prose Add prose detection guard (looksLikeAssistantProse) so error-detection heuristics in sanitizeUserFacingText only fire on short, single-line text that resembles actual API errors—not multi-sentence assistant responses. Also tighten isBillingErrorMessage loose keyword branch to skip prose, preventing false classification of normal text discussing billing topics. Fixes openclaw#12676 Co-Authored-By: Claude <[email protected]>
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| // JSON error payloads are always worth catching regardless of length. | ||
| if (isRawApiErrorPayload(trimmed)) { | ||
| return "The AI service returned an error. Please try again."; | ||
| } | ||
|
|
||
| // Skip heuristic error detection for text that looks like normal assistant | ||
| // prose - long responses, multi-paragraph, markdown-formatted, etc. | ||
| // This prevents false positives where normal responses discussing topics | ||
| // like "Error handling" or "402 payment required" get replaced. | ||
| if (looksLikeAssistantProse(trimmed)) { | ||
| return stripped; | ||
| } |
There was a problem hiding this comment.
Long errors bypass sanitization
looksLikeAssistantProse() returns true for any text over 500 chars, and sanitizeUserFacingText returns early in that case. This means any real error text that happens to be verbose (>500 chars)—e.g. gateway/proxy HTML, stack traces, or multi-sentence provider errors—will skip isLikelyHttpErrorText / ERROR_PREFIX_RE handling and be shown to users un-sanitized. If the intent is only to avoid false positives on assistant prose, consider restricting the prose guard to non-error-prefixed messages (or only skipping the heuristic branches, not all sanitization) so long true errors still get replaced.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/agents/pi-embedded-helpers/errors.ts
Line: 294:305
Comment:
**Long errors bypass sanitization**
`looksLikeAssistantProse()` returns true for any text over 500 chars, and `sanitizeUserFacingText` returns early in that case. This means any *real* error text that happens to be verbose (>500 chars)—e.g. gateway/proxy HTML, stack traces, or multi-sentence provider errors—will skip `isLikelyHttpErrorText` / `ERROR_PREFIX_RE` handling and be shown to users un-sanitized. If the intent is only to avoid false positives on assistant prose, consider restricting the prose guard to non-error-prefixed messages (or only skipping the heuristic branches, not all sanitization) so long true errors still get replaced.
How can I resolve this? If you propose a fix, please make it concise.
Additional Comments (1)
Prompt To Fix With AI |
|
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
|
Closing as superseded by the merged sanitize/error-context work:
This PR’s intent appears covered by those merged changes and current mainline tests. |
2 participants
Summary
Fixes #12676
sanitizeUserFacingTextapplies error-detection heuristics to all outbound messaging text, including normal assistant responses. When an assistant discusses topics like billing, error handling, or HTTP status codes, the heuristic pattern-matching can misclassify the response as an API error and replace it with a generic error message.Changes
looksLikeAssistantProse()guard that detects multi-sentence text, paragraph breaks, and markdown formatting — structural signals that distinguish assistant prose from short API error messagesisRawApiErrorPayloadcheck (JSON structure) before the prose guard since JSON payloads are always worth catchingisLikelyHttpErrorText,ERROR_PREFIX_RE) when text looks like proseisBillingErrorMessageloose keyword branch (billing+upgrade/credits/payment/plan) to also skip prose textTest Plan
pi-embedded-helperstests passpnpm lint,pnpm build,pnpm formatall pass🤖 Generated with Claude Code (issue-hunter-pro)
Greptile Overview
Greptile Summary
This PR updates
sanitizeUserFacingTextto reduce false-positives where normal assistant prose (multi-paragraph text, markdown, multi-sentence explanations) was being misclassified as an API error and replaced with a generic error message. It introduces alooksLikeAssistantProse()guard, moves JSON error-payload detection earlier, and tightens the billing “loose keyword” heuristic to avoid classifying assistant discussions about billing as real billing errors. Tests were added to cover multi-paragraph/markdown/billing-topic prose while preserving sanitization for short, actual error-like strings.Confidence Score: 3/5
isBillingErrorMessagelowercases before applyinglooksLikeAssistantProse, breaking its sentence heuristic, and (2) the early prose return bypasses all heuristic sanitization for any text >500 chars, which can expose verbose real errors.