fix(commitments): keep emoji / surrogate pairs intact during terminal output truncation#101605
fix(commitments): keep emoji / surrogate pairs intact during terminal output truncation#101605maweibin wants to merge 1 commit into
Conversation
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Close as superseded: the open maintainer-labeled UTF-16 sweep already carries this exact commitments helper change, adds caller-level regression coverage, and has broader Testbox proof, so this branch should not remain a separate landing path. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Canonical path: Use #101654 as the canonical landing path for this UTF-16 truncation fix, and only revive this narrow branch if the consolidated sweep does not land. So I’m closing this here and keeping the remaining discussion on #101654. Review detailsBest possible solution: Use #101654 as the canonical landing path for this UTF-16 truncation fix, and only revive this narrow branch if the consolidated sweep does not land. Do we have a high-confidence way to reproduce the issue? Yes from source inspection: current main truncates commitment table cells with raw UTF-16 slicing before appending an ellipsis, so a surrogate pair at the cutoff can leave a dangling high surrogate. I did not run the full CLI path locally during this read-only review. Is this the best way to solve the issue? No for keeping this branch as the best landing path. The updated code is correct for the narrow commitments helper, but the consolidated PR is the better solution because it covers this exact change, sibling truncation surfaces, regression tests, and broader proof together. Security review: Security review cleared: The diff only changes local TypeScript string formatting and imports an existing internal helper; it does not touch dependencies, workflows, secrets, permissions, package metadata, or code-execution paths. 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. |
… output truncation .use Array.from() to count full code points instead of UTF-16 code units, preventing lone surrogates in commitment list output. Co-Authored-By: Claude Opus 4.8 <[email protected]>
1aedead to
5d4f0ab
Compare
|
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
The commitment list formatter in
src/commands/commitments.tstruncates table cells 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�inopenclaw commitmentsCLI output.This is user-visible: commitment descriptions are user-provided text that can contain emoji near the column width boundary of 16 characters (id) or 90 characters (suggested text).
Why This Change Was Made
Replace
.slice()withtruncateUtf16Safe()from@openclaw/normalization-core/utf16-sliceso truncation counts full code points instead of UTF-16 code units. This matches the already-merged PR #101517 (session-cost-usage).User Impact
openclaw commitmentstable cells no longer show�when commitment descriptions contain emoji near column boundaries.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 terminal output. Cell width caps are unchanged — the broken surrogate is dropped cleanly rather than rendered as�.What was not tested: full
openclaw commitmentsend-to-end run on exact PR head (production CLI uses installed binary).Regression Test Plan
AI-assisted.