[spoukyii]

Problem

A preview annotation's context chip takes its label from the annotation's comment through previewAnnotationContextLabel in apps/web/src/lib/composerContextRecords.ts. That function cuts a comment longer than 48 UTF-16 code units at 47 units and appends …, before the shared sanitizeComposerContextLabel runs. When an emoji straddles that cut, the label keeps only its high surrogate:

Expected: 46 "a"s, then "…"
Received: 46 "a"s, a lone high surrogate (U+D83D, shown as �), then "…"

The broken label shows in the composer chip. It is also stored in the context record and the chip reference sent with the message, and it seeds the thread title when the message has no text of its own.

Expected: the cut never splits a character, as #29158 made the shared chip label cap do.

Change

When the cut would land between a high and a low surrogate, it steps back one unit. That is the check #29158 added to sanitizeComposerContextLabel. The 48-unit limit, the … suffix, the page-title fallback and every label without a split emoji are unchanged.

Scope and approval

This is a very small, focused fix for an obvious bug. It is the defect #29158 ("context chip labels no longer split an emoji at the 200-character cap") fixed in the shared chip label cap, still present in the preview annotation's own, shorter cut that runs before it. It applies the same check and changes no other behaviour, setting or contract.

Two open PRs change the same file. #29804 makes clampContextText surrogate-safe for terminal and review text and does not touch this label. #29834 changes previewAnnotationContextRecord and adds a test in the same test file; this PR's test sits at a different spot. A trial merge of this branch with the current heads of both is clean.

Verification

apps/web/src/lib/composerContextRecords.test.ts gets one case beside the other annotation record tests. It builds the record for an annotation whose comment is 46 as followed by 😀, so the emoji sits on the cut.

On main with only the test commit (941f304), from apps/web, vp test run src/lib/composerContextRecords.test.ts:

 FAIL  src/lib/composerContextRecords.test.ts > composerContextRecords > shortens a long annotation comment label without splitting an emoji
Expected: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa…"
Received: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa�…"
      Tests  1 failed | 14 passed (15)

With the fix, from apps/web:

• vp test run src/lib/composerContextRecords.test.ts src/components/ChatView.logic.test.ts: 2 files, 62 tests passed.
• vp run check:changed from the repo root: format, lint, knip, typecheck (2 packages), tests beside the change and the React Compiler check all pass.

To see it in the app: open a page in the preview, add an annotation, and type a comment of 46 ASCII characters followed by an emoji and more text. The chip that lands in the composer reads …a�… on main and …a… with the fix.

What I could not check: the chip in a running client. The test covers the label function that the chip, the record and the title fallback all read. Like #29158, the cut works per code point, so it can still split a grapheme cluster such as a flag or a ZWJ sequence; it never leaves a lone surrogate.

Bug: a preview annotation chip label ends in a broken character when an emoji sits at the cut

This was written with Claude Opus 5.5 in Claude Code, driven from T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at 4c16851

Macroscope's review found this PR approvable — Preview annotation labels now avoid cutting a Unicode surrogate pair at the truncation boundary. The change is limited to label presentation and leaves annotation content and existing defaults unchanged.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The preview annotation label truncation now avoids splitting a UTF-16 surrogate pair. A test checks that a long label containing an emoji ends with an ellipsis without splitting the emoji.

Changes: Preview annotation labels

Layer / File(s)	Summary
Safe label truncation apps/web/src/lib/composerContextRecords.ts, apps/web/src/lib/composerContextRecords.test.ts	The label truncation adjusts its slice boundary when it would split a surrogate pair. A test checks this behavior with an emoji.

Estimated code review effort: 2 (Simple) | ~5 minutes

Change: Bug fix · Severity of issue fixed: Low

Suggested reviewers: juliusmarminge

Merge Risk: Minimal · up to 4c168

The preview label fix is mergeable with no identified current-head risk.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: preview annotation chip labels no longer end in a broken character. The raw summary confirms the code change stops the 47-unit cut from splitting a surrogate pair in p…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description check		The description follows the template closely. It covers Problem, Change, Scope and approval, and Verification. The Problem section states the defect, the expected behavior, and the broken output. The …

Full details: Title check

Explanation

The title names the main change: preview annotation chip labels no longer end in a broken character. The raw summary confirms the code change stops the 47-unit cut from splitting a surrogate pair in previewAnnotationContextLabel, so the title matches the changeset. It is concise and follows the conventional commit format.

Full details: Description check

Explanation

The description follows the template closely. It covers Problem, Change, Scope and approval, and Verification. The Problem section states the defect, the expected behavior, and the broken output. The Change section explains the one-unit step-back and what stays the same. The Scope section argues the fix qualifies as a very small, focused fix of an obvious bug, and it ties the fix to the earlier #29158 fix. The Verification section gives the exact failing and passing test commands and their results, and it states what was not checked, which is the running client chip. The template's required screenshot is not applicable because the author did not include a UI before/after screenshot. The author did describe the observed chip text, but did not attach evidence. The author also did not state the model and harness in the required closing line. The author did state the model in the footer, so that requirement is met. Overall the description is mostly complete.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

CodeRabbit Verify

• Run CodeRabbit Verify to test the changes in this pull request.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 550c5fa
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: d3e1bec1-ba8e-4755-a5da-9b22f2f291dc

Commits

Reviewing files that changed from the base of the PR and between 550c5fa and 4c16851.

Files selected for processing: 2

• apps/web/src/lib/composerContextRecords.test.ts
• apps/web/src/lib/composerContextRecords.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 5 remain after this review.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified as-is at 4c16851fb07297156d6f28d65edf9cccee885911 on a linux boat vm. no source changes or pushes were needed.

• reproduced on github/main (7c22e24e3f) in a separate worktree after vp i. selected a real page element in the desktop browser, entered 46 as followed by 😀 and make the button bigger, and attached it. the composer label contained a lone high surrogate before the ellipsis.
• checked out the exact pr head, ran vp i, and started the real development server with isolated state. the same fresh annotation now has exactly 46 as followed by …, with no lone surrogate. matching composer crops are below.
• drove the web app with repository playwright and /usr/bin/google-chrome. annotation creation is exposed by the desktop preview bridge, so exercised that flow in the actual linux electron client with playwright. desktop development required libsecret-1-dev; used electron's --password-store=basic to avoid creating or unlocking a keyring.
• sent the annotation through the desktop composer to real codex gpt-6.1-sol. its response reproduced the full comment including 😀 and confirmed the screenshot and Example Domain page title. the sent chip retained the shortened label after a client reload.
• neighboring checks passed: a short Keep emoji 😀 intact label stays unchanged; an empty comment uses Example Domain; the details popover retains the full comment and screenshot; keyboard removal clears the annotation.
• ran the existing composerContextRecords.test.ts and ChatView.logic.test.ts through blacksmith-check: 2 files and 62 tests passed. current head ci has no failing or pending checks.

before, main:

after, pr head:

real provider response:

12-second recording of annotation attach, details, and removal:

Not verified

native ios/android, macos/windows desktop, other providers, remote/relay/tunnel connections, and annotation-only thread title seeding were not exercised. the web server browser has no annotation creation control, so the changed creation flow was verified through desktop. this change protects surrogate pairs; complete grapheme-cluster truncation remains outside its scope.