[Bug] Web composer: Lexical error #14 (infinite transform loop) and amber/missing text when typing after a claimed slash-command token

[kaijia323]

Environment

• DSH 0.1.5-alpha.1» (@deepseek-ai/dsh-client-ui-conversation@0.1.5-alpha.1», npm `alpha» dist-tag, published 2026-09-08)
• Windows 11 · Microsoft Edge (also reproduced on Chrome) · Microsoft Pinyin IME
• Bundled Lexical `0.49.0»

Summary

In the Web composer, typing after a claimed slash-command token (e.g. `/plan» followed by text) intermittently:

1. renders the newly typed text in the claim color (amber) instead of the normal text color;
2. drops/loses the characters just typed; and/or
3. throws Minified Lexical error #14» from the composer's onError: (error) => { throw error }», leaving the composer broken until a page refresh.

Screenshot — the seat where it happens (claimed `/plan» token in amber, followed by typed text):

The screenshot shows the normal state; in the faulty runs the text after `/plan» also turns amber, or disappears.

Steps to reproduce

1. Open any session in the Web GUI and focus the composer.
2. Type `/plan» and let the command claim settle — the token turns amber. Do not press Enter.
3. Keep typing after the token (Chinese via Microsoft Pinyin, e.g. `暗色的阿松大», or simply extra characters).
4. Intermittently the new text turns amber, or vanishes; sometimes the composer throws error 求一个memory能力 #14.

Observed error

Uncaught Error: Minified Lexical error #14; visit https://lexical.dev/docs/error?code=14 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
    at t (client.js:3303:1)
    at di (client.js:7232:1)
    at Js (client.js:8745:1)
    at Wo.getWritable (client.js:5343:1)
    at Wo.setTextContent (client.js:5786:1)
    at Wo.mergeWithSibling (client.js:5891:1)
    at Ft$1 (client.js:3879:1)
    at Pt$1 (client.js:3898:1)
    at client.js:7533:1
    at Mi (client.js:7550:1)

Frame mapping (against dsh-client-ui-conversation/lib/client.js» + lexical@0.49.0»):

frame	function
`t»	`invariant»
`di»	errorOnInfiniteTransforms» — infiniteTransformCount > 99 && invariant(false)»
`Js»	node-write dirty marking
`Wo.*»	TextNode.getWritable» / setTextContent» / `mergeWithSibling»
`Ft$1»	`$mergeWithSibling»
`Pt$1»	`$normalizeTextNode»
client.js:7533» / Mi»	dirty-leaf reconciliation loop

Note: #14 is the "transforms endlessly triggering additional transforms" guard, not "Unable to find an active editor state" (that is #195 in the same build).

Root cause

packages/client/ui-conversation/src/client/input/editor/claim-decor.ts» (registerClaimDecoration», introduced with the Lexical composer rewrite `b519cb87»), lines 43-47:

if (text.length > token.length) {
  // Typing at the token boundary lands in the styled node; split the
  // overflow back out so only the token itself carries the color.
  const [tokenNode] = node.splitText(token.length)
  if (tokenNode !== undefined && tokenNode.getStyle() !== TOKEN_STYLE) tokenNode.setStyle(TOKEN_STYLE)
  return
}

TextNode.splitText» copies style» to every part (lexical/src/nodes/LexicalTextNode.ts:1017-1019» reads style» once; :1040-1052» applies it to each part). When the token leaf is **already** styled with TOKEN_STYLE» and then gains trailing text — the normal incremental-typing path — both halves keep TOKEN_STYLE». $normalizeTextNode» sees equal mode»/format»/`style» and merges them back into one styled node; the transform splits again on the next pass; after 100 reconciliation passes Lexical throws #14.

Which symptom appears depends on dirty-leaf processing order:

• overflow transform runs first → it hits the "off the token seat" branch and clears its style → converges, text stays black;
• first-leaf normalization runs first → merge → amber overflow text and/or 求一个memory能力 #14;
• an aborted commit loses the characters typed in that update.

Chinese IME makes it frequent and intermittent because composition updates repeatedly replace the same text node, flipping the dirty-leaf order from keystroke to keystroke.

The existing test packages/client/ui-conversation/tests/lexical-editor-core.client.spec.tsx:428-465» inserts /plan rest» in a single update (leaf starts unstyled, so it splits once and converges). It never exercises the incremental path (style first, then append), which is why this slipped through.

Minimal headless repro (no DSH needed)

Run with `lexical@0.49.0»; it reproduces the exact 10-frame stack:

// node repro-lexical-14.cjs   (requires lexical@0.49.0)
const L = require('lexical/dist/Lexical.prod.js');
const TOKEN = '/plan';
const STYLE = 'color: var(--dsw-alias-state-warn-label)';

const firstTextLeaf = () => {
  const block = L.$getRoot().getFirstChild();
  const leaf = L.$isElementNode(block) ? block.getFirstChild() : null;
  return L.$isTextNode(leaf) ? leaf : null;
};

const editor = L.createEditor({ namespace: 'repro' });
editor.registerNodeTransform(L.TextNode, (node) => {
  const first = firstTextLeaf();
  if (first === null || node.getKey() !== first.getKey()) {
    if (node.getStyle() === STYLE) node.setStyle('');
    return;
  }
  const text = node.getTextContent();
  if (!text.startsWith(TOKEN)) {
    if (node.getStyle() === STYLE) node.setStyle('');
    return;
  }
  if (text.length > TOKEN.length) {
    const [tokenNode] = node.splitText(TOKEN.length);
    if (tokenNode !== undefined && tokenNode.getStyle() !== STYLE) tokenNode.setStyle(STYLE);
    return;
  }
  if (node.getStyle() !== STYLE) node.setStyle(STYLE);
});

// 1) type the token — the claim decoration styles it amber
editor.update(() => {
  const p = L.$createParagraphNode();
  p.append(L.$createTextNode(TOKEN));
  L.$getRoot().append(p);
}, { discrete: true });

// 2) type one more character at the token boundary -> Minified Lexical error #14
editor.update(() => {
  firstTextLeaf().setTextContent(TOKEN + 'x');
}, { discrete: true });

Result: Minified Lexical error #14» with t → Ur → li → getWritable → setTextContent → mergeWithSibling → St → Tt → anon → ss» — the same shape as the shipped stack.

Proposed fix

Make the overflow segment drop `TOKEN_STYLE» after the split, so normalization cannot re-merge the halves:

if (text.length > token.length) {
  const [tokenNode, overflow] = node.splitText(token.length)
  if (tokenNode !== undefined && tokenNode.getStyle() !== TOKEN_STYLE) tokenNode.setStyle(TOKEN_STYLE)
  if (overflow !== undefined && overflow.getStyle() === TOKEN_STYLE) overflow.setStyle('')
  return
}

A regression test should drive the incremental path (create the claimed token, then insert one character) and assert: token amber, overflow unstyled, no #14.

Notes

• Filed here because GitHub Issues are disabled on this repo; CONTRIBUTING directs bug reports to Discussions.
• 0.1.5-alpha.1» is the current alpha» tag; lib/client.js:12036-12068» matches master»'s `claim-decor.ts», so this is not fixed as of that build.
• Only the official bundles are installed locally (plus a sidebar plugin that is unrelated — the repro above needs no plugins).
• Stack analysis and the minimal repro script were prepared with DeepSeek assistance.

---

中文摘要

Web 输入框在已 claim 的斜杠命令 token 之后继续输入时（如 /plan» 后接着输入中文），偶现三种表现：新输入的文字变成琥珀色（claim token 的颜色）、刚输入的字丢失、或直接抛 Minified Lexical error #14»（`errorOnInfiniteTransforms»，transform 死循环 100 轮保护）。

根因在 packages/client/ui-conversation/src/client/input/editor/claim-decor.ts:43-47»：splitText(token.length)» 会把 style» 复制给前后两段，于是 token 段和溢出段都带 TOKEN_STYLE»；Lexical 的 $normalizeTextNode» 认为两段可合并，又把它们并回一个染色节点，transform 下一轮再拆 → 死循环。谁先跑决定结果：溢出段先清样式就正常（黑字），首叶先合并就变黄/报错；提交中断则丢字。中文 IME 组合输入反复改写同一文本节点，所以偶现。现有测试 tests/lexical-editor-core.client.spec.tsx:428-465» 是一次性插入 `/plan rest»，没有覆盖“先染色再增量输入”的路径。

最小复现脚本与修复建议见上文；截图见帖子顶部。

[TT-Wang]

Independent reproduction on 0.1.6-alpha.2 (ddefc45fbc, 2026-09-17, which is also today's master): still present. The only change to claim-decor.ts since your report is eff482c46b (2026-09-09), which rewrote the activeToken() comparison (trimEnd) and left the splitText branch untouched; the file is otherwise identical at 0.1.3-alpha.2 / 0.1.5-rc.1 / rc.2 / 0.1.6-alpha.1 / alpha.2. Two things worth adding to the record.

1. It is deterministic, not intermittent — the collapsed selection's style decides. Real Chromium 152, isolated DSH_HOME, no plugins, built-in /goal (any leadingInput command works; bare commands such as /help never claim):

after the claim (menu pick, token amber)	DOM	console
type straight away	/goal [amber] + a[plain]	—
← →, then type	/goal [amber] + x[plain]	—
mouse-click back into the composer (~1 s later), then type	one amber span /goal x, placeholder still painted over it	Uncaught Error: Minified Lexical error #14 — and again on every further keystroke

Why: the claim and the arrow-key moves are Lexical-driven DOM selection updates, so $updateDOMSelection calls markCollapsedSelectionFormat(…, style: '') and the following selectionchange (inside the 200 ms window in onSelectionChange) keeps style = ''; RangeSelection.insertText then sees formatDiffers and puts the new character in a fresh unstyled node. A mouse click is a user selectionchange outside that window, so the selection takes the anchor node's style ($updateSelectionFormatStyleFromTextNode), insertText goes through spliceText, and the character lands inside the token node — from there it is exactly your loop (splitText copies __style to the overflow → $normalizeTextNode merges the two same-style nodes before transforms run → split again → guard at 100). IME composition end feeds the node through the same in-node path, which matches your Pinyin case (not exercised here).

2. The rethrow is what turns one bad keystroke into a dead composer. Headless (@lexical/headless 0.49.0, upstream claim-decor.ts unmodified, selection style = token style, insertText('x')): 200 transform invocations, then the guard. With the composer's onError: (error) => { throw error } (runtime.ts:59) the $beginUpdate catch stops at _onError, _pendingEditorState is never rolled back, and the next harmless editor.update throws again — every keystroke from then on. With a non-throwing onError, Lexical's own recovery branch restores the pre-keystroke state: the typed character is lost but the editor keeps working — that is your "drops the characters" symptom, so both symptoms come from the same loop.

Fix check. Clearing the copied style on the overflow node —

const [tokenNode, overflow] = node.splitText(token.length)
if (tokenNode !== undefined && tokenNode.getStyle() !== TOKEN_STYLE) tokenNode.setStyle(TOKEN_STYLE)
if (overflow !== undefined && overflow.getStyle() === TOKEN_STYLE) overflow.setStyle('')

— makes both in-node paths (selection-driven insertText and direct setTextContent, i.e. the IME/MutationObserver route) converge in 4 transform calls with /goal [token] + x[plain], and also removes the "new text turns amber" symptom. tests/lexical-editor-core.client.spec.tsx:428-460 covers the claim/unclaim style flip but not the "styled node grows" path, so a one-case addition there would pin it.

Minimal headless repro (drop into packages/client/ui-conversation/, run with the repo's tsx; swap sel.style = leaf.getStyle() for sel.style = '' to get the non-triggering control):

import { createHeadlessEditor } from '@lexical/headless'
import { $createParagraphNode, $createRangeSelection, $createTextNode, $getRoot, $setSelection } from 'lexical'
import { registerClaimDecoration } from './src/client/input/editor/claim-decor.ts'

const editor = createHeadlessEditor({ namespace: 'r', nodes: [], onError: (e) => { throw e } })
registerClaimDecoration(editor, () => '/goal ')
editor.update(() => { const p = $createParagraphNode(); p.append($createTextNode('/goal ')); $getRoot().append(p) }, { discrete: true })
editor.update(() => {
  const leaf = $getRoot().getFirstChild()!.getFirstChild()!   // already carries TOKEN_STYLE
  const sel = $createRangeSelection()
  sel.anchor.set(leaf.getKey(), 6, 'text'); sel.focus.set(leaf.getKey(), 6, 'text')
  sel.style = leaf.getStyle()                                  // what a mouse click / IME leaves on the collapsed selection
  $setSelection(sel); sel.insertText('x')                      // → "One or more transforms are endlessly triggering additional transforms"
}, { discrete: true })

(Also filed on the internal tracker.)