fix(errors): prevent billing false positive in sanitizeUserFacingText by lailoo · Pull Request #13467 · openclaw/openclaw

lailoo · 2026-02-10T15:12:23Z

Summary

Problem

sanitizeUserFacingText() unconditionally applies isBillingErrorMessage() to all user-facing text. The isBillingErrorMessage function uses a broad heuristic that matches any text containing both "billing" and one of "payment", "upgrade", "credits", or "plan". This causes assistant-generated content discussing billing/payment topics (e.g., gym membership billing details) to be replaced with the generic billing error warning.

Fix

Add a shouldRewriteBillingText() guard function (matching the existing shouldRewriteContextOverflowText() pattern) that distinguishes real billing errors from assistant prose:

Precise billing patterns (402, insufficient credits, credit balance, payment required, plans & billing) are rewritten unconditionally — these are unambiguous error strings.
Broad heuristic matches (billing + payment/upgrade/credits/plan) are only rewritten when the text looks like a raw error message (API payload, HTTP error, error prefix, or single-sentence without markdown/paragraphs).

Reproduction & Verification

Unit-level (direct function call):

Before fix (main branch) — Bug reproduced:

--- Assistant content (should NOT be rewritten) ---
  "**Billing:** Processed through ABC Financial Services..."  ❌ FALSE POSITIVE
  "The gym membership billing cycle runs monthly..."           ❌ FALSE POSITIVE
  "Here is a summary of the billing and payment options..."    ❌ FALSE POSITIVE

After fix — All verified:

--- Assistant content (should NOT be rewritten) ---
  ✅ PASS (all assistant content samples preserved)

--- Real billing errors (SHOULD be rewritten) ---
  ✅ PASS: "insufficient credits"
  ✅ PASS: "billing: please upgrade your plan"
  ✅ PASS: "Your credit balance is too low"

Integration-level (real gateway reply pipeline):

Added normalizeReplyPayload integration tests in src/auto-reply/reply/normalize-reply.test.ts that exercise the full reply normalization pipeline (normalizeReplyPayload → sanitizeUserFacingText):

Before fix (main branch) — Bug reproduced through real pipeline:

normalizeReplyPayload({ text: "**Billing:** ... payments ..." })
  → text: "⚠️ API provider returned a billing error..."  ❌ FALSE POSITIVE

After fix — Pipeline preserves assistant content:

normalizeReplyPayload({ text: "**Billing:** ... payments ..." })
  → text: "**Billing:** Processed through ABC Financial Services..."  ✅ PRESERVED

normalizeReplyPayload({ text: "insufficient credits" })
  → text: "⚠️ API provider returned a billing error..."  ✅ REWRITTEN

Effect on User Experience

Before fix:
Sub-agent researches gym membership details → output contains "Billing: ... payments" → parent receives "⚠️ API provider returned a billing error" instead of actual findings.

After fix:
Assistant content discussing billing/payment topics is delivered as-is. Real billing errors (402, insufficient credits, etc.) are still correctly caught and rewritten.

Testing

✅ 14 unit tests pass (12 existing + 2 new regression tests in sanitizeuserfacingtext.test.ts)
✅ 2 new integration tests pass (normalizeReplyPayload pipeline in normalize-reply.test.ts)
✅ isBillingErrorMessage() unchanged — error classification for failover/logging still works

greptile-apps

_{1 file reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-10T15:21:21Z

src/agents/pi-embedded-helpers/errors.ts

+  const hasMultipleSentences = /[.!?]\s+[A-Z]/.test(raw);
+  const hasMarkdown = /[*_#[\]|]/.test(raw);
+  const hasParagraphs = raw.includes("\n\n");
+  return !hasMultipleSentences && !hasMarkdown && !hasParagraphs;


Lowercase sentence false positive
hasMultipleSentences uses /[.!?]\s+[A-Z]/ (errors.ts:169), so multi-sentence prose where the next sentence starts lowercase (e.g., "... . payment is ...") is treated as single-sentence and will still be rewritten if it matches the broad billing heuristic. This undermines the goal of not rewriting assistant prose; consider using a sentence boundary check that doesn’t rely on capitalization (or a different prose-vs-error heuristic).

Prompt To Fix With AI

This is a comment left during a code review. Path: src/agents/pi-embedded-helpers/errors.ts Line: 169:172 Comment: **Lowercase sentence false positive** `hasMultipleSentences` uses `/[.!?]\s+[A-Z]/` (errors.ts:169), so multi-sentence prose where the next sentence starts lowercase (e.g., "... . payment is ...") is treated as single-sentence and will still be rewritten if it matches the broad billing heuristic. This undermines the goal of not rewriting assistant prose; consider using a sentence boundary check that doesn’t rely on capitalization (or a different prose-vs-error heuristic). How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-10T15:21:22Z

src/agents/pi-embedded-helpers/errors.ts

+  // Single-sentence short texts without markdown are likely error messages.
+  const hasMultipleSentences = /[.!?]\s+[A-Z]/.test(raw);
+  const hasMarkdown = /[*_#[\]|]/.test(raw);
+  const hasParagraphs = raw.includes("\n\n");
+  return !hasMultipleSentences && !hasMarkdown && !hasParagraphs;


One-sentence prose still rewritten
The fallback return !hasMultipleSentences && !hasMarkdown && !hasParagraphs; (errors.ts:168-172) will rewrite any single-sentence assistant content that happens to contain billing plus payment/upgrade/credits/plan (the broad heuristic). If the intent is to only rewrite raw error strings on the broad path, this condition is too permissive; a one-sentence paragraph of prose will be replaced by BILLING_ERROR_USER_MESSAGE.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/agents/pi-embedded-helpers/errors.ts Line: 168:172 Comment: **One-sentence prose still rewritten** The fallback `return !hasMultipleSentences && !hasMarkdown && !hasParagraphs;` (errors.ts:168-172) will rewrite any single-sentence assistant content that happens to contain `billing` plus `payment/upgrade/credits/plan` (the broad heuristic). If the intent is to only rewrite raw error strings on the broad path, this condition is too permissive; a one-sentence paragraph of prose will be replaced by `BILLING_ERROR_USER_MESSAGE`. How can I resolve this? If you propose a fix, please make it concise.

…openclaw#13434)

…false positive (openclaw#13434)

…xt per Greptile feedback (openclaw#13434)

openclaw-barnacle bot added the agents Agent runtime and tooling label Feb 10, 2026

lailoo mentioned this pull request Feb 10, 2026

False positive: Sub-agent output about billing/payments incorrectly flagged as API error #13434

Closed

greptile-apps bot reviewed Feb 10, 2026

View reviewed changes

lailoo force-pushed the fix/billing-false-positive-13434 branch from 6c5aa15 to 3b6fe1f Compare February 11, 2026 02:19

lailoo added 3 commits February 13, 2026 12:25

fix(errors): prevent billing false positive in sanitizeUserFacingText (…

ce9335b

…openclaw#13434)

test(errors): add normalizeReplyPayload integration test for billing …

db71164

…false positive (openclaw#13434)

fix(errors): remove broad prose heuristic from shouldRewriteBillingTe…

9e04f79

…xt per Greptile feedback (openclaw#13434)

lailoo force-pushed the fix/billing-false-positive-13434 branch from 3b6fe1f to 9e04f79 Compare February 13, 2026 04:27

openclaw-barnacle bot added size: S trusted-contributor Contributor with 4+ merged PRs labels Feb 13, 2026

dominicnunez mentioned this pull request Feb 14, 2026

Refactor: thread structured error classification through sanitizer pipeline #16521

Open

thewilloftheshadow force-pushed the main branch from bfc1ccb to f92900f Compare February 15, 2026 18:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(errors): prevent billing false positive in sanitizeUserFacingText#13467

fix(errors): prevent billing false positive in sanitizeUserFacingText#13467
lailoo wants to merge 3 commits intoopenclaw:mainfrom
lailoo:fix/billing-false-positive-13434

lailoo commented Feb 10, 2026 •

edited

Loading

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Feb 10, 2026

Uh oh!

greptile-apps bot Feb 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Comments

Uh oh!

Conversation

lailoo commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Problem

Fix

Reproduction & Verification

Unit-level (direct function call):

Integration-level (real gateway reply pipeline):

Effect on User Experience

Testing

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Comments

lailoo commented Feb 10, 2026 •

edited

Loading