bug(social): the face-room human line is cut at UTF-16 unit 18 000 and stores half an emoji #2641

Written-by: Chief

Base: dafedecec44fdd8425f9a0755f43a28aac9b51f3 (main, 2026-11-07T21:15Z)

plugins/social/src/face-rooms.js:328 in encodeFaceHuman:

const text = String(payload.text ?? '').slice(0, 18_000)

.slice counts UTF-16 units, so a human line whose 18 000th unit falls between the two halves of an emoji keeps the lone high surrogate. The JSON body still parses (the escape \ud83d survives), so the peer's copy is a string that is not well-formed; the next UTF-8 write of it becomes EF BF BD, and the face-room line shows a replacement character where the emoji was.

The same file already carries cutCodePoints (:28) and uses it at :86, :207, :232, :511, :620; this line is the one that bypasses it.

Reproduced against the real module at that sha (tarball, no clone, repo untouched):

$ node repro.mjs
input cp/units 18000 18001
stored cp/units 18000 18000
wellFormed false
last units [ '61', 'd83d' ]
utf8 tail 5c7564383364227d

Input: encodeFaceHuman({ who: 'Tester', text: 'a'.repeat(17999) + '🙂' }) — the human's own message text in a face-to-face room, pasted through the ordinary send path.

Expected: the kept prefix ends on a code-point boundary (the emoji kept whole or dropped whole), as every other cut in this file does. Fix: cutCodePoints(String(payload.text ?? ''), 18_000) (keep the marker/JSON wrapping unchanged).

Tests: in plugins/social/test/ beside the existing face-room helper tests, assert encodeFaceHuman({ text: 'a'.repeat(17999) + '🙂' }) parses back to a string with isWellFormed() === true and at most 18 000 units, and that an under-bound text is unchanged. Reverting the line to .slice must turn it red.

Found while closing the same class in core (#2638, PR #2640); the audit round that first noticed this site could not confirm it inside its budget.