fix(memory): snippets split emoji when truncated#102478
Conversation
…rrogate-truncation
…rrogate-truncation
|
Codex review: needs maintainer review before merge. Reviewed July 9, 2026, 3:10 AM ET / 07:10 UTC. Summary PR surface: Source +22, Tests +42. Total +64 across 5 files. Reproducibility: yes. Current main visibly uses raw Review metrics: none identified. Stored data model 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 this narrow helper/test fix after exact-head merge and CI gates; broader byte-decoding or grapheme-cluster improvements should be handled separately if they are observed. Do we have a high-confidence way to reproduce the issue? Yes. Current main visibly uses raw Is this the best way to solve the issue? Yes. The package-local helper is the narrowest maintainable fix for these host SDK call sites because it preserves the existing memory-host boundary and avoids importing the broad runtime facade into lightweight string/result helpers. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against c20ce00d19ec. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +22, Tests +42. Total +64 across 5 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
|
|
Land-ready at exact head Review improvement: replaced the newly added package-local UTF-16 truncation implementation with the canonical dependency-free Proof:
No known proof gaps. |
|
Merged via squash.
|
* fix(memory): snippets split emoji when truncated * refactor(memory): reuse shared UTF-16 truncation --------- Co-authored-by: Peter Steinberger <[email protected]>
What Problem This Solves
Fixes an issue where users reading truncated memory excerpts or provider response error snippets could see malformed text when the truncation boundary landed inside an emoji or other UTF-16 surrogate pair.
Why This Change Was Made
This keeps memory-host snippet truncation on a UTF-16-safe boundary within the package-local string helper layer, then applies that same invariant to both response snippets and single-line memory read excerpts. The change stays inside the memory-host SDK boundary and preserves the existing continuation notice behavior, including when the safe visible prefix is empty.
User Impact
Truncated memory and response snippets no longer expose dangling surrogate halves or replacement-character-style output when text contains emoji near the character cap. Memory read results still tell users how to continue or fall back to the raw source line when the excerpt is capped.
Evidence
node scripts/run-vitest.mjs packages/memory-host-sdk/src/host/response-snippet.test.ts packages/memory-host-sdk/src/host/read-file-shared.test.tspassed on branchcodex/fix-memory-surrogate-truncationwith 2 files and 8 tests passing.git diff --check upstream/main...HEADpassed.python .agents\skills\autoreview\scripts\autoreview --mode branch --base upstream/mainpassed with no accepted/actionable findings.readResponseTextSnippetreturnsabc... [truncated]for an emoji split at the cap, andbuildMemoryReadResultFromSlicereturns a continuation notice without preserving a dangling surrogate when a leading emoji is dropped.