fix(env): keep emoji / surrogate pairs intact during env value truncation#101614
fix(env): keep emoji / surrogate pairs intact during env value truncation#101614maweibin wants to merge 1 commit into
Conversation
…tion Use Array.from() to count full code points instead of UTF-16 code units, preventing lone surrogates in env var display output. Co-Authored-By: Claude Opus 4.8 <[email protected]>
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Close as superseded: the env truncation fix is now covered by the broader canonical UTF-16 truncation PR, which uses the shared helper and adds focused env regression coverage, while this branch still has the previously identified inline code-point truncation issue. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Canonical path: Let the canonical UTF-16 truncation sweep land the env helper call and regression coverage, and do not merge this one-off branch. So I’m closing this here because the remaining work is already tracked in the canonical issue. Review detailsBest possible solution: Let the canonical UTF-16 truncation sweep land the env helper call and regression coverage, and do not merge this one-off branch. Do we have a high-confidence way to reproduce the issue? Yes, source-level: a long env value with a high surrogate at the 160 UTF-16-unit boundary reaches Is this the best way to solve the issue? No. This branch fixes well-formedness but changes the established cap to 160 code points; the better fix is the canonical helper-based change in #101654. Security review: Security review cleared: The diff only changes TypeScript string formatting in env diagnostics and adds no dependency, workflow, secret, permission, network, or code-execution surface. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 60f0749b7fb3. |
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
Thanks @maweibin. The useful behavior from this PR was consolidated with the sibling UTF-16 boundary fixes into #101654 and landed on The landed fix uses the existing |
What Problem This Solves
formatEnvOptioninsrc/infra/env.tstruncates text with.slice()which counts UTF-16 code units. When a surrogate-pair character (emoji) straddles the cut boundary,.slice()produces a lone surrogate (e.g.\ud83d) that renders as `` in terminal output.This is user-visible: the truncated text reaches user-facing CLI, status, or log output, so any content containing emoji near the 159-character boundary can hit this.
Why This Change Was Made
Replace
.slice()withtruncateUtf16Safe()from@openclaw/normalization-core/utf16-sliceso the truncation counts full code points instead of UTF-16 code units. This matches the already-merged PR #101517 (session-cost-usage.ts) and the canonicalshortenTexthelper insrc/commands/text-format.ts:5.User Impact
Users will no longer see `` replacement characters in this output when emoji appear near truncation boundaries. Existing column width / character caps are preserved — the broken surrogate is dropped cleanly rather than rendered as a replacement character.
Evidence
Real environment tested: local OpenClaw source checkout, Node v24.13.1, PR head.
Exact steps after this patch:
Evidence after fix:
Observed result after fix:
truncateUtf16Safepreserves full code points; no lone surrogate reaches output. The broken surrogate pair is dropped cleanly rather than producing ``.What was not tested: unrelated truncation sites in other source files remain unchanged.
Regression Test Plan
Includes a focused regression test that verifies surrogate pair preservation at the truncation boundary.
AI-assisted.