Summary

• Keep Nextcloud Talk error-body snippets UTF-16 safe when a long response body is collapsed for user-visible errors.
• Add a local HTTP-server regression through sendMessageNextcloudTalk so the failing body crosses the real send/error path.

Maintainer verification

• Frozen head: 33c26657224b5af89484d33915c165f311b6ca29 (includes an exact thrown-Error assertion for the malformed-surrogate regression).
• Exact-head CI: run 29030125468 completed successfully: 59 checks succeeded, one CodeQL check was neutral, 30 routine checks were skipped, and none failed or remained pending.
• Sanitized AWS green: run run_fff37b03fe84 fetched the remote PR at the frozen SHA through the trusted untrusted-source bootstrap and passed the complete Nextcloud Talk suite: 16 files, 101 tests.
• Sanitized AWS control red: run run_32cee4fec874 started from the same frozen SHA, replaced only the helper call with the former raw slice(0, 200) behavior in its ephemeral remote worktree, and the focused regression failed as expected: one failed, one passed. The received message contained the split-surrogate replacement character. The mutated lease was discarded.
• Fresh autoreview: clean, no actionable findings, 0.91 confidence.
• Known live-proof gap: no external Nextcloud instance was used. The regression crosses a real local HTTP request/response boundary through the exported send API; the changed behavior is the local post-response formatter.

What Problem This Solves

Nextcloud Talk error responses are bounded and then shortened before being included in send/reaction errors. The old formatter used slice(0, NEXTCLOUD_TALK_ERROR_SNIPPET_MAX_CHARS), so a response body with an emoji or other astral character starting at the truncation boundary could leave a lone UTF-16 surrogate in the thrown error message.

Latest origin/main still has the raw slice at extensions/nextcloud-talk/src/send.ts:

origin/main=4f9a371c9530e9d2eb2912a44054a44228a59612
32:    return `${collapsed.slice(0, NEXTCLOUD_TALK_ERROR_SNIPPET_MAX_CHARS)}…`;

User Impact

• Why it matters / User impact: Users sending to a Nextcloud Talk room can receive malformed or replacement-character snippets in the CLI/runtime error when the self-hosted server returns a long Unicode error body. The fix keeps the snippet readable and avoids surfacing half of a surrogate pair.

Origin / follow-up

Follows #102833.

• Follows: fix(lifecycle): keep install output truncation UTF-16 safe #102833 fixed the same UTF-16 boundary class for install failure summaries by replacing raw prefix slicing with truncateUtf16Safe.
• Gap: Nextcloud Talk retained the same raw prefix truncation in its error-body snippet formatter.
• Consistency: This applies the same shared UTF-16-safe truncation pattern to the channel error path without changing request construction, status handling, or body byte limits.

Competition / linked PR analysis

• Related open PR scan: checked open PRs for nextcloud-talk UTF-16 error snippet in openclaw/openclaw before submission.

[]

No open same-point PR was found.

Merge risk

• Risk labels considered: message-delivery, availability, compatibility, security-boundary, session-state, automation.
• Risk explanation: The only relevant risk surfaces for this patch are message-delivery and availability because it touches extensions/nextcloud-talk/src/send.ts. The change runs after an HTTP response is already non-OK and only changes the formatter for the bounded response snippet. It does not alter delivery requests, auth/signing, timeout behavior, success parsing, state/session handling, security policy, or background execution.
• Why acceptable: The diff is limited to one truncation helper call and one regression test. The byte cap remains enforced by readResponseTextLimited; the thrown error still includes the same status-specific prefix and ellipsis. The only behavior change is avoiding invalid UTF-16 when the snippet limit lands inside an astral code point.
• Patch quality notes: Focused source change plus a regression that crosses the exported channel send path with a local HTTP server. No skip/only directives, no type escapes, no fallback/default strategy, no package dependency change, and no unrelated cleanup.
• Maintainer-ready confidence: High: latest main still has the raw slice, there is no open same-point PR, the fix uses an existing shared helper, and the local server proof exercises the user-visible error path.

Real behavior proof

• Behavior or issue addressed: A long Nextcloud Talk error response whose 200th UTF-16 code unit lands inside an emoji should not surface a malformed half-surrogate in the thrown send error.
• Canonical reachability path: user/config/input → schema/type/ingestion/normalization → runtime object → request/effect: user target/message/config input (room:abc123, hello, channels.nextcloud-talk.baseUrl, botSecret, and private-network opt-in) is accepted as CoreConfig by sendMessageNextcloudTalk, resolved by resolveNextcloudTalkSendContext / resolveNextcloudTalkAccount into runtime account/baseUrl/secret, sent as a signed POST request to /ocs/v2.php/apps/spreed/api/v1/bot/abc123/message, receives a non-OK Unicode response body from the local Nextcloud-compatible endpoint, passes through readResponseTextLimited and collapseErrorSnippet, then becomes the thrown user-visible Nextcloud Talk: bad request - ... effect.
• Boundary crossed: The regression uses withServer to run an actual local HTTP server, receives the real POST from sendMessageNextcloudTalk, returns HTTP 400 with a Unicode text body, and observes the thrown error from the exported send API.
• Shared helper / provider constraint check: The fix uses truncateUtf16Safe from openclaw/plugin-sdk/text-utility-runtime, the existing SDK text helper backed by OpenClaw's UTF-16-safe truncation utility. The existing readResponseTextLimited byte budget remains unchanged.
• Real environment tested: Linux local worktree, Node/Vitest, local HTTP server via openclaw/plugin-sdk/test-env; no mocked fetch in the regression proof.
• Exact steps or command run after this patch:

source /media/vdb/code/ai/aispace/openclaw-followup-102833-evidence/context.env
cd "$TASK_WORKTREE"
node scripts/run-vitest.mjs extensions/nextcloud-talk/src/send.fetch-timeout.test.ts
node scripts/run-vitest.mjs extensions/nextcloud-talk/src/send.cfg-threading.test.ts

• Evidence after fix:

[test] starting test/vitest/vitest.extension-messaging.config.ts

 Test Files  1 passed (1)
      Tests  2 passed (2)
...
[test] passed 1 Vitest shard in 24.02s

[test] starting test/vitest/vitest.extension-messaging.config.ts

 Test Files  1 passed (1)
      Tests  12 passed (12)
...
[test] passed 1 Vitest shard in 17.65s

origin/main=4f9a371c9530e9d2eb2912a44054a44228a59612
32:    return `${collapsed.slice(0, NEXTCLOUD_TALK_ERROR_SNIPPET_MAX_CHARS)}…`;

• Observed result after fix: The local server regression exercises the exported send path and expects the thrown message to be exactly Nextcloud Talk: bad request - ${prefix}… for prefix = "e".repeat(199), proving the emoji that straddles the boundary is dropped instead of leaving a lone surrogate.
• What was not tested: I did not use a real external Nextcloud instance. The changed behavior is the local formatter for any non-OK HTTP response body after the response has already crossed the fetch boundary, and the proof covers that boundary with a local HTTP server.
• Fix classification: Root cause fix

Review findings addressed

No maintainer review findings exist for this new follow-up branch. Pre-submit checks covered the known follow-up risks: latest main still has the raw slice gap, no same-point open PR was found, and the regression crosses the exported send path with a local HTTP server.

Regression Test Plan

• Target test file: extensions/nextcloud-talk/src/send.fetch-timeout.test.ts for the new local-server UTF-16-safe error snippet regression; extensions/nextcloud-talk/src/send.cfg-threading.test.ts for existing send/reaction error-path coverage.
• Scenario locked in: A 400 response body constructed as "e".repeat(199) + "\u{1F600}tail" crosses the real POST path and then hits the snippet limit at the emoji's surrogate pair boundary.
• Why this is the smallest reliable guardrail: It asserts the exported send API's thrown error after a real local HTTP response, so it covers request construction, response handling, bounded body reading, snippet formatting, and user-visible error propagation without requiring unrelated Nextcloud infrastructure.

node scripts/run-vitest.mjs extensions/nextcloud-talk/src/send.fetch-timeout.test.ts
node scripts/run-vitest.mjs extensions/nextcloud-talk/src/send.cfg-threading.test.ts
git show origin/main:extensions/nextcloud-talk/src/send.ts | grep -n "collapsed\.slice(0, NEXTCLOUD_TALK_ERROR_SNIPPET_MAX_CHARS)"

Risk / Compatibility

The output remains bounded and still appends the same ellipsis for overlong snippets. The only observable change is that truncation will not split a surrogate pair; snippets may be one UTF-16 code unit shorter when the limit lands inside an astral character.

What was not changed

• What did NOT change: Does not change Nextcloud Talk auth, signature generation, request body construction, room token normalization, SSRF policy, timeout handling, success response parsing, reaction status handling, the error-body byte cap, or package dependencies.
• Architecture / source-of-truth check: Source-of-truth boundary: collapseErrorSnippet is the canonical source formatter used by readNextcloudTalkErrorSnippet before both send and reaction errors are thrown. This patch fixes that formatter rather than post-processing a mirror, projection, log copy, or test-only representation.

Root Cause

• Root cause: Root cause is the source formatter collapseErrorSnippet shortening collapsed error bodies with raw JavaScript slice(0, 200). Because JavaScript string indices are UTF-16 code units, slicing at an arbitrary code-unit boundary can cut between the high and low surrogate of an emoji or another astral code point.
• Why this is root-cause fix: The patch replaces the raw code-unit slice at the single snippet formatter with the shared UTF-16-safe truncation helper. Every non-OK Nextcloud Talk response body still flows through the same formatter, so the invalid-surrogate source is removed before the message is assembled.