fix(signal): truncate verbose inbound preview on code-point boundaries#97982
fix(signal): truncate verbose inbound preview on code-point boundaries#97982solodmd wants to merge 1 commit into
Conversation
|
Codex review: needs maintainer review before merge. Reviewed June 29, 2026, 10:43 PM ET / 02:43 UTC. Summary PR surface: Source 0, Tests +52. Total +52 across 2 files. Reproducibility: yes. at source level: current main calls Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Next step before merge
Security Review detailsBest possible solution: Land the focused Signal logging fix after ordinary maintainer review and required-check gating; any broader sibling-channel preview cleanup should be handled separately. Do we have a high-confidence way to reproduce the issue? Yes, at source level: current main calls Is this the best way to solve the issue? Yes. Reusing the existing Plugin SDK AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 54b09580f61b. Label changesLabel justifications:
Evidence reviewedPR surface: Source 0, Tests +52. Total +52 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
49f054c to
23b73da
Compare
Signal verbose inbound message previews truncate with body.slice(0, 200), which can split a UTF-16 surrogate pair when an emoji straddles position 200, producing a lone high surrogate in the debug log. Use truncateUtf16Safe from openclaw/plugin-sdk/text-utility-runtime so the preview always lands on a valid code-point boundary. Tests: 5 new tests covering the straddling-emoji boundary, emoji-before- boundary, plain ASCII truncation, position-0 edge case, and short-body pass-through. Co-Authored-By: Claude <[email protected]>
23b73da to
442322f
Compare
|
Closing this as superseded by the broader UTF-16-safe truncation fix now on main: c16bb87. I kept this as one canonical pass instead of landing the one-off PRs separately so Browser, Discord, Feishu, iMessage, MS Teams, Signal, Twitch, and Voice Call preview/error truncation all use the shared UTF-16 helpers consistently. Thanks for flagging this surface. Proof for the landed commit:
|
What Problem This Solves
Signal verbose inbound message previews truncate the message body with
body.slice(0, 200). When an emoji or other astral character straddlesposition 200, the raw slice keeps only the high-surrogate half, producing
a lone
\uD83Din the debug log — malformed UTF-16.Why This Change Was Made
The plugin SDK provides
truncateUtf16Safefor this exact pattern. Otherchannel plugins (Discord, Feishu, Telegram, Tlon, Mattermost, Slack)
already use it for the same purpose.
User Impact
No user-facing behavior change. The verbose debug log now emits valid
UTF-16 previews regardless of where emoji fall in the truncated message.
Evidence
git diff --check origin/main...HEADpnpm test extensions/signal— 30 files, 375 tests passed.agents/skills/autoreview/scripts/autoreview --mode branch --base origin/mainAfter-fix Proof
Boundary probe on this PR branch:
Tests
extensions/signal/src/monitor/event-handler.truncation.test.ts— 5 testscovering the straddling-emoji boundary, emoji-before-boundary, plain ASCII
truncation, position-0 edge case, and short-body pass-through.