Description

editor.registerUpdateListener is documented as something to "watch out for infinite loops" with, but there is no runtime detection. When a listener calls editor.update() and the resulting state change is dirty enough to fire the listener again, the chain runs synchronously through $triggerEnqueuedUpdates → $beginUpdate → commit → listener → _updates.push → $triggerEnqueuedUpdates ... until the browser hangs. The existing infiniteTransformCount counter resets per $beginUpdate, so it can't catch a cascade that crosses update lifecycles.

Fix

Add a per-editor _cascadeCount counter that increments in $triggerEnqueuedUpdates when the queue is non-empty and resets when the chain naturally drains or the editor is reset. Once the counter exceeds the threshold, surface a cascade-specific invariant through editor._onError and clear the pending update queue so the chain is cut even if the user's onError swallows the throw. The counter is editor-instance state rather than module-level because a listener on editor A can synchronously call editor.update() on editor B; sharing the counter would let A's cascade exhaust B's budget.

Closes #3694

Design notes

• The try/catch wraps only the cascade-detection invariant, not the surrounding $beginUpdate call, so it doesn't intercept the deliberate re-throw from $commitPendingUpdates's reconciler-recovery path.
• Threshold matches the existing infiniteTransformCount (99).

Test plan

• pnpm vitest run --project unit packages/lexical/src/__tests__/unit/LexicalEditor.test.tsx — 79 tests pass (new "Detects infinite recursivity on update listeners" alongside the existing transform-recursivity test)
• pnpm vitest run --project unit — 2585 tests pass, no NestedEditor regression
• pnpm tsc --noEmit -p tsconfig.json clean
• pnpm flow clean
• npx prettier --check clean on changed files