[zurfyx]

Parked (10/30)

This PR is parked as a draft. The branch and its tests stay as they are. Its goal, S9-5, is tracked in #9609; the tests move to main in #9605, with the cases main fails as expected failures.

Why. Rule 5 (a restore writes a null of its own right after the end of the run it relies on) was extended to runs the writing client opened itself, to fix S9-5: a comment's restore after uncommented text its author typed inside it, whose end a long offline peer's delete drops, ran on over the rest of the document. Each attempt to make that extension safe regressed a case main handles, each found in review, each fix reopening an earlier case:

1. b8c4175: the hole scan (opensHole) took a format change's real end for a hole when its client later typed plain text and applied the same format elsewhere (bold a word, type, bold another word), so a collaborator's restore inside that run got no null and the bold ran to the end of the document (S7-24's original case).
2. 5a34d5c: a randomized two-client run-sequence fuzz (format a run, type plain text, format a second run or the writer's own just-typed word, undo one to three of those writes while a collaborator types plain text inside the first run) failed 187 to 228 of 1,000 seeds, against 9 on main.
3. 6ff4537 (rule 5 back to main's opener rule, own runs included): one write inside the author's own comment is enough. The restore's null sits right after the comment's end; a collaborator who has seen that write deletes past the end, with another comment's items in the gap the delete collapses; collapseGap keeps the new null (the key's last item) and deletes the comment's own end, and the author's concurrent undo removes the null: the comment covers the rest of the document. Main keeps the end there.

The collapse problem. Cursor#collapseGap keeps, besides each key's last item, the last earlier item with the same value only where another client wrote it (otherClient, around Cursor.ts:990). An own-run null from a different write of the same client is the same client, so it wins over the run's own end, which is deleted. Protecting a same-client item from another write there (or keeping each client's first same-valued item, as 89e03fd did) brought back the offline spread in one session.

What a redesign needs. The binding cannot tell, from the document alone, which write an item of the same client belongs to or which end a restore relies on: every rule here inferred it from clocks and positions, and each inference had a counterexample. Either a provenance marker (the restore records the end it relies on, so a collapse can keep exactly that end), or a different approach to S9-5 that does not add a second null of the same client next to the run's end (for example, the offline peer's delete keeping the run ends a later restore relies on).

---

Current state (narrowed after review, ac2c143a + 6ff45373)

The change is now main's rule 5 with two differences, in Cursor.ts only:

• restatedEnd no longer skips runs the writing client opened itself (the offline-return spread described below: a restore inside one's own comment run gets its own end after the run).
• A write puts at most one null of its own after a given end (endedInThisWrite).

The hole-scanning machinery added in 83df52d3, b8c41752 and 5a34d5cc (runChain, opensHole, followsText) is removed: a randomized run-sequence fuzz (one client writes a format, plain text, then the same format; a collaborator types plain text inside the first run while the writer undoes) failed 187 of 1,000 seeds with it against main's 9. The narrowed rule fails exactly main's 9 seeds; RunSequenceUndo.test.ts (200 seeds) expects exactly main's failing seed. The bullets for those three commits further down describe what they did then; their scan is gone.

Known limits, each pinned in OwnRunRestoreEnd.test.ts:

• More than 64 structs in the comment change (not a regression). The own-run end is found only where changeEnd finds where the comment change ended, and its scan of the author's structs stops at 64: with 1, 16 or 64 comment ids the restore now ends after the run in both client-id orders; with 128 it gets none and every comment spreads to the rest of the document, as on main (which fails all of these cells). test.fails naming Bug: [lexical-y] A restore inside a run whose format change has more than 64 items gets no end of its own, so the format spreads to the rest of the document #9603.
• The Bug: [lexical-y] A collaborator's format that starts where your own format run ends is lost when you change part of that run at the same time #9589 tie, now in two shapes (a regression against main, accepted). With the author's client id higher, a collaborator's format that starts at the end of the author's own run, or runs from inside it past its end while the author types plain text inside it, is lost after the run's end on every client: the author's own-run null and the collaborator's opener share their origins. No text is lost, the clients converge, and the format comes back if the author undoes. main keeps the collaborator's format there because it writes no own-run null; it is accepted because without that null the author's offline restore lets the comment spread over every later word, on every client. test.fails for ids [2, 1] naming Bug: [lexical-y] A collaborator's format that starts where your own format run ends is lost when you change part of that run at the same time #9589, regular tests for [1, 2]; [lexical-website][lexical-y] Documentation Update: Say which list conversions are moves, and add an undo race and a join race to the @lexical/y limits #9569 documents both shapes.
• S9-12b and Bug: [lexical-y] A comment spreads onto later words when two collaborators undo text they typed inside it while a third deletes past its end #9575 as below.

Reviewed on 6ff45373 by gpt-5.6-sol (clean, with #9603's bound and the #9589 tie accepted; independent matrices over one/two inserts, same/other-client ownership, both id orders and 1/16/64/128 ids). An independent non-GPT adversarial review found the second #9589 shape, now pinned.

Description

When a client inserts text without a value inside a run of that value (uncommented text typed inside a comment, plain text inside bold), it restores the value after its text and relies on the item that ends the run. Rule 5 of Cursor#format makes a restore whose run another client's change opened write a null of its own right after that change's end, because that end can go while the restore stays: the change's undo deletes it, and a concurrent delete may drop it (a delete keeps a bounded number of the format items it leaves in a run of deleted content).

Two cases were left out, and in both the restored value ran on to the end of the document after a collaborator's concurrent delete dropped the run's end:

• The writer opened the run itself. restatedEnd skipped runs this client opened. A collaborator's delete that has not seen the restore can still drop that end. For example, a client comments a word and later, offline, types into it while a collaborator deletes text next to the commented word, which was deleted earlier. When the client comes back, the comment covers every later word on every client.
• The run was opened by a write that also restored it. For example, a comment written with uncommented text inside it, in one write. The run's end is then the end the restore wrote, but the check compared against the null before that text (the opener's changeEnd), so no own end was written.

Now a restore gets its own end after the end of any write in the chain that gave the run its value (the opener, or a restore in it: runChain, which replaces runOpener), whichever client wrote it. The extra null is written only where a restore is written, right after an end that already exists, so it adds at most one item per such insert, and the bounded collapse can remove it later like any other item (the growth-bound tests pass unchanged).

Changeset

.changeset/lexical-y-own-run-restore-end.md: @lexical/y patch.

Test plan

New packages/lexical-y/src/__tests__/unit/OwnRunRestoreEnd.test.ts, run in both client id orders:

• A comments "Kilo", then types uncommented "X" inside it; B deletes the word, then deletes the comment's opener and end with raw Yjs deletes (for B they bracket deleted content only), standing in for a concurrent deletion of that end such as the bounded collapse.
• The comment is written with uncommented "X" inside it, then A types uncommented "Y" inside it.

Each test expects nothing after the word to carry the comment.

pnpm exec vitest run --project unit packages/lexical-y/src/__tests__/unit/OwnRunRestoreEnd.test.ts

Before

 × ... ends where the comment ended when a collaborator's delete drops the comment's end (ids 1,2)
 × ... ends where the comment ended when the comment was written with a hole in it (ids 1,2)
 × ... ends where the comment ended when a collaborator's delete drops the comment's end (ids 2,1)
 × ... ends where the comment ended when the comment was written with a hole in it (ids 2,1)
AssertionError: expected 'aa X bb[c1] cc[c1]' to be 'aa Xbb cc' // Object.is equality
AssertionError: expected 'aa Y bb[c1] cc[c1]' to be 'aa Ybb cc' // Object.is equality
      Tests  4 failed (4)

With only the own-client exemption removed, the second test still fails in both orders. With only the chain change, the first does.

After

      Tests  4 passed (4)

The follow-up commits add one case to this file for the fix described under "Randomized sessions found after opening" (it fails on this branch without them and passes on main); the file now has 8 tests: 6 pass and the 2 orders of S9-12b are expected failures (the known gap below).

• pnpm exec vitest run --project unit packages/lexical-y: 165 files passed (7483 tests, 46 expected fail), no failures. With the follow-up commits, packages/lexical-y and packages/lexical-mark: 181 files passed (8646 tests, 46 expected fail).
• pnpm run ci-check passes.
• In a randomized long-session soak (2 people and an agent, 2 simulated hours), the four sessions that showed this spread now show none: 12, 8, 8 and 4 unexplained formatted words become 0. Twenty-four other sessions show the same results with and without the change.
• Extended fuzz (FUZZ_SEED_START=50000 FUZZ_SEEDS=2000): the same seven seeds fail with and without the change, with the same messages, so none of them comes from it.

Randomized sessions found after opening

• A link undone spreads onto untouched words (fixed for one write, follow-up commits). One write restored the link's run at two places, and each restore put a null of the writer's own right after the same end. A collaborator's Cursor#collapseGap keeps a key's last items, so it kept the two nulls and deleted the end, and the writer's undo of that write removed both nulls: nothing ended the run. A write now puts at most one null of its own after a given end (Cursor#endedInThisWrite). A first attempt that instead made the collapse keep more items was reverted in the next commit: it brought back the offline-return spread this change fixes in one of the four sessions above. The new OwnRunRestoreEnd.test.ts case (one write, two inserts) fails without it; the session passes. Known gap: two separate writes of one client that each restore inside its own run and are both undone while a collaborator collapses past the run's end still lose the end (each write adds a null of its own there; main writes none for the writer's own run). It is pinned as the test.fails case "S9-12b" in OwnRunRestoreEnd.test.ts (its body passes on main). The same loss with three clients' nulls after one end also happens on main: Bug: [lexical-y] A comment spreads onto later words when two collaborators undo text they typed inside it while a third deletes past its end #9575. Both are accepted as documented limits (rare, and no text is lost): the Undo bullet of @lexical/y's Limits gets a sentence covering them in [lexical-website][lexical-y] Documentation Update: Say which list conversions are moves, and add an undo race and a join race to the @lexical/y limits #9569 ("A comment or format can run on past its end when writes inside it are undone ... while another client deletes text across its end"), and the S9-12b test.fails pin stays. [lexical-y] Bug Fix: Keep the run ends of text an undo removes, and end a value an undo ends past other writes' run ends #9561, stacked on this PR, makes S9-12b pass.

• An editor that differs from a fresh read of its own document (two sessions): not a binding divergence. In both, the client applied an update past a struct still pending on a missing dependency. Yjs 14 integrates it past the gap and shows it, but a load of that client's own encoding leaves those structs pending too, so the soak's fresh read lacked them until the dependency arrived; then both agree. Without this change the same happens for any update that arrives past a pending one: on main, plain Yjs (C inserts "C"; B, which has it, inserts "b" after it and then "X" at the start; J applies B's two updates only) gives j="Xhello world" against a reload of its encoding "hello world", and both read "XhelloCb world" once C's update arrives. This is Structs past a clock gap: stuck pending structs, and a doc that differs from its own encoding (v14) yjs/yjs#824 (a doc that differs from its own encoding past a clock gap); with Fix pending structs around clock gaps in the struct store yjs/yjs#827 the reload also reads "Xhello world". This change makes it more frequent only because its null's origin is the run's end, which can be far from the cursor. y.md already documents it ("Deliver each client's updates in order"). A soak oracle should compare an editor with a fresh read only once its doc holds no pending structs (or run on a Yjs with Refactor isAttached method #827).

• A comment spread over untouched words in a 1-hour, 3-person session: not reproduced with this change's current stack. On the identical operation trace (2,249 ops) it appears only with an earlier revision of [lexical-y] Bug Fix: Keep the run ends of text an undo removes, and end a value an undo ends past other writes' run ends #9561 merged on top. This change alone, this change with [lexical-y] Bug Fix: Keep the run ends of text an undo removes, and end a value an undo ends past other writes' run ends #9561's current head, and the same integration with [lexical-y] Bug Fix: Keep the run ends of text an undo removes, and end a value an undo ends past other writes' run ends #9561's current head leave no spread.

• A later write's hole taken as the run's end (review follow-up, 83df52d3; scan removed in ac2c143a). restatedEnd accepted, for a restore link of the run's chain, the first later item of the key the restore's client wrote; when that restore put no null of its own, that item is the null opening the same client's next hole, which rule 5 says is no end. Another client's restore in front of that hole then wrote a null right after it, and the hole author's undo ended the comment early (aa Kil[c1] X o[c1] Q m[c1] etY er[c1] instead of main's ... Q met[c1] Y er[c1]; with bold, "et" lost the format). A candidate end that its client follows with its own text and a restore of the run's value now opens a hole and is not an end. The review's case is in OwnRunRestoreEnd.test.ts for a comment and for bold, in both id orders: 4 failed before; the file now has 10 passing tests and the 2 S9-12b expected failures.

• A hole missed when many comments share the range (review follow-up, b8c41752; scan removed in ac2c143a). The check above scanned at most 64 items after a candidate end, so with 64 comment ids on the range it missed the hole and an undo removed the comments from untouched text. It now scans the write's own items by phase (format items, then text, then format items) with no fixed cap; a 64-comment case is in OwnRunRestoreEnd.test.ts (it fails on 83df52d3).

• A collaborator's format starting where your own run ends (accepted limit, Bug: [lexical-y] A collaborator's format that starts where your own format run ends is lost when you change part of that run at the same time #9589). If A removes a format from part of its own run while B applies it to text starting at that run's end, A's own rule-5 null and B's opener tie in Yjs's order; with A's client id higher, B's text loses the format on every client (no text is lost; main keeps it in this own-run case, and has the same tie for runs another client opened). Placement cannot win that tie without giving up what rule 5 protects. It is pinned in OwnRunRestoreEnd.test.ts (ids [2, 1] as test.fails naming Bug: [lexical-y] A collaborator's format that starts where your own format run ends is lost when you change part of that run at the same time #9589, ids [1, 2] as a regular test), the follow-up repair is Bug: [lexical-y] A collaborator's format that starts where your own format run ends is lost when you change part of that run at the same time #9589, and [lexical-website][lexical-y] Documentation Update: Say which list conversions are moves, and add an undo race and a join race to the @lexical/y limits #9569 adds it to the Limits next to S9-12b and Bug: [lexical-y] A comment spreads onto later words when two collaborators undo text they typed inside it while a third deletes past its end #9575.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
lexical	Ready	Preview	Oct 30, 2026 5:16pm UTC
lexical-playground	Ready	Preview	Oct 30, 2026 5:16pm UTC

[pkg-pr-new]

lexical

npm i https://pkg.pr.new/lexical@9562

@lexical/a11y

npm i https://pkg.pr.new/@lexical/a11y@9562

@lexical/clipboard

npm i https://pkg.pr.new/@lexical/clipboard@9562

@lexical/code

npm i https://pkg.pr.new/@lexical/code@9562

@lexical/code-core

npm i https://pkg.pr.new/@lexical/code-core@9562

@lexical/code-prism

npm i https://pkg.pr.new/@lexical/code-prism@9562

@lexical/code-shiki

npm i https://pkg.pr.new/@lexical/code-shiki@9562

@lexical/compiler

npm i https://pkg.pr.new/@lexical/compiler@9562

@lexical/devtools-core

npm i https://pkg.pr.new/@lexical/devtools-core@9562

@lexical/dragon

npm i https://pkg.pr.new/@lexical/dragon@9562

@lexical/eslint-plugin

npm i https://pkg.pr.new/@lexical/eslint-plugin@9562

@lexical/extension

npm i https://pkg.pr.new/@lexical/extension@9562

@lexical/fast-check

npm i https://pkg.pr.new/@lexical/fast-check@9562

@lexical/file

npm i https://pkg.pr.new/@lexical/file@9562

@lexical/hashtag

npm i https://pkg.pr.new/@lexical/hashtag@9562

@lexical/headless

npm i https://pkg.pr.new/@lexical/headless@9562

@lexical/history

npm i https://pkg.pr.new/@lexical/history@9562

@lexical/html

npm i https://pkg.pr.new/@lexical/html@9562

@lexical/internal

npm i https://pkg.pr.new/@lexical/internal@9562

@lexical/link

npm i https://pkg.pr.new/@lexical/link@9562

@lexical/list

npm i https://pkg.pr.new/@lexical/list@9562

@lexical/mark

npm i https://pkg.pr.new/@lexical/mark@9562

@lexical/markdown

npm i https://pkg.pr.new/@lexical/markdown@9562

@lexical/mdast

npm i https://pkg.pr.new/@lexical/mdast@9562

@lexical/offset

npm i https://pkg.pr.new/@lexical/offset@9562

@lexical/overflow

npm i https://pkg.pr.new/@lexical/overflow@9562

@lexical/plain-text

npm i https://pkg.pr.new/@lexical/plain-text@9562

@lexical/react

npm i https://pkg.pr.new/@lexical/react@9562

@lexical/rich-text

npm i https://pkg.pr.new/@lexical/rich-text@9562

@lexical/selection

npm i https://pkg.pr.new/@lexical/selection@9562

@lexical/table

npm i https://pkg.pr.new/@lexical/table@9562

@lexical/tailwind

npm i https://pkg.pr.new/@lexical/tailwind@9562

@lexical/text

npm i https://pkg.pr.new/@lexical/text@9562

@lexical/utils

npm i https://pkg.pr.new/@lexical/utils@9562

@lexical/y

npm i https://pkg.pr.new/@lexical/y@9562

@lexical/yjs

npm i https://pkg.pr.new/@lexical/yjs@9562

commit: 6ff4537

[meta-code-review]

Thanks for the detailed write-up and the two-commit split. Both behaviours hold up: the four headline cases in OwnRunRestoreEnd.test.ts fail on main and pass here, and the S9-12 cases fail with only the first commit and pass with the collapseGap change, so the second commit is clearly needed by the first.

The own-run null can erase a collaborator's concurrent format that starts where the run ends (packages/lexical-y/src/internal/Cursor.ts:657, written at :608-613)

With the own-client exemption removed from restatedEnd, a client that writes a restore inside a run it opened itself now inserts a null right after the run's end, with that end as its origin and the following content as its right origin. A collaborator who formats text starting at that same end at the same time keeps the end and opens its value right after it (format rule 2, :1303-1316), with the same origin and right origin. Yjs breaks that tie by client id, so when the restoring client's id is the higher one, the null lands between the collaborator's opener and its text, and the collaborator's format disappears from its whole range on every peer. On aa Kilo bb cc, with A = client 2 and B = client 1:

Concurrent edits	main	this PR
A bolds Kilo, later types plain X inside it; B bolds bb	bb bold	bb plain
A bolds Kilo, later removes bold from il; B bolds bb	bb bold	bb plain
A comments Kilo as c1, later types uncommented X inside it; B adds c1 to bb	bb in c1	bb not in c1

With ids 1, 2 all three keep B's format. main already behaves this way when another client opened the run (B bolds Kilo, A types plain X inside it, B bolds bb): the placement rule 5 documents ("right after the end, not before it", Cursor.ts:1167-1171) protects text typed at the end of the run, not an opener placed there. This PR extends that to runs the writing client opened itself, such as editing inside formatting you made yourself. The Limits section of packages/lexical-website/docs/collaboration/y.md lists the concurrent edits that do not merge as a user might expect, and this one is not among them.

A test in the style of OwnRunRestoreEnd.test.ts (add $setSelection to the lexical import) fails here with ids [2, 1] and passes on main:

const $bold = (from: number, to: number) => () => {
  const sel = $selectIn([0], from, to);
  sel.format = (sel.anchor.getNode() as TextNode).getFormat();
  sel.formatText('bold');
  $setSelection(null);
};

test(`keeps a collaborator's bold that starts where the author's bold ends (ids ${ids})`, async () => {
  const t = await setup(
    () => $getRoot().append($p('aa Kilo bb cc'), $p('tail line')),
    {ids, prepare},
  );
  t.a.update($bold(3, 7));
  await t.sync();
  t.offline();
  t.a.update($bold(4, 6)); // A removes bold from "il" of its own bold word
  t.b.update($bold(7, 10)); // B bolds " bb", starting where that word ends
  await t.sync();
  await expectConverged(t.peers);
  expect(t.a.describe()).toContain('"o bb"{1}');
});

Could the rule-5 null be placed, or followed up, so that it cannot separate another client's concurrent opener from its text? That would also fix the main case. If the trade-off is intended, please pin it with tests in both id orders and add it to the Limits list in y.md.

Smaller points

• The two headline tests drop the comment's end with raw Item#delete calls (dropCommentItems, OwnRunRestoreEnd.test.ts:63-83). If one of the soak sessions can be reduced to binding operations whose delete collapse drops the end, that case would show the binding reaching the state on its own.
• The cases you deferred, three clients' items after the end (#9575) and reads past a pending struct (covered in y.md under "Deliver each client's updates in order"), also happen on main, so they are not blockers here.

[meta-code-review]

With the own-client exemption gone, this now also returns the end of a run the writing client opened itself, and insertNegatedFormats writes a null right after it (:608-613). A collaborator's concurrent format that starts at that end opens its value right after the same end (format rule 2, :1303-1316), so the two items share an origin and a right origin and Yjs orders them by client id. When the restoring client's id is higher, the null sits between the collaborator's opener and its text and that format is lost on every peer: A bolds Kilo, then removes bold from il while B bolds bb, and bb ends up plain with ids [2, 1] (it stays bold on main). The main comment has a test for it.

[meta-code-review]

Thanks for the detailed write-up, the reproductions in both client-id orders, and for pinning the known gap instead of leaving it implicit. One regression needs a fix before this lands.

1. A restore link in runChain can take a later write's hole as the run's end (packages/lexical-y/src/internal/Cursor.ts:681, changeEnd at :152)

restatedEnd now accepts changeEnd(doc, c) for every link c of the chain. For a restore link, changeEnd returns the first item of the key, with another value, that the restore's client wrote after it in clock order. When that restore's own write put no rule-5 null (for example because its run ended at another client's hole), that item is the null opening the same client's next hole in the run, which is exactly the null the rule 5 comment says "is no such end" (Cursor.ts:1155-1157). Another client's restore in front of that hole then writes a null right after it; when the hole's author undoes that write, the hole's null and restore are deleted, the extra null stays, and the rest of the word loses the comment on every peer. No concurrency or offline step is needed. Added to OwnRunRestoreEnd.test.ts (it reuses words and $insertPlainAt), this passes on main and fails here:

test(`a later write's hole is not a run end (ids ${ids})`, async () => {
  const t = await setup(
    () => $getRoot().append($p('aa Kilometer bb cc'), $p('tail line')),
    {ids, prepare},
  );
  t.a.update(() => void $addMarkID('c1', $selectIn([0], 3, 12)));
  await t.sync();
  t.b.update(() => $insertPlainAt(10, 'Y')); // after "Kilomet"
  await t.sync();
  t.a.update(() => $insertPlainAt(6, 'X')); // after "Kil"
  await t.sync();
  t.a.update(() => $insertPlainAt(9, 'Z')); // after "om", a second write
  await t.sync();
  t.b.update(() => $insertPlainAt(8, 'Q')); // after "o"
  await t.sync();
  t.a.undo(); // removes "Z"
  await t.sync();
  await expectConverged(t.peers);
  // this branch: 'aa Kil[c1] X o[c1] Q m[c1] etY er[c1] bb cc'
  expect(words(t.a)).toBe('aa Kil[c1] X o[c1] Q met[c1] Y er[c1] bb cc');
});

The same steps with bold (formatText('bold') instead of the comment) leave "et" plain. After B types "Q", B's null sits right after A's null that opens the "Z" hole, because changeEnd of A's first restore is that null. Keeping the own-client change but going back to comparing only with the opener's end makes the case pass. One direction: do not accept a candidate end that its client follows with a restore of the run's value after its own text, or bound changeEnd on a restore link to that restore's own write.

2. S9-12b is a regression against main (OwnRunRestoreEnd.test.ts:228-260)

Its body passes on main; on this branch the comment runs on over cc dd and the next paragraph. The test.fails documents it well. Since #9575 covers the four-client variant (three nulls from two collaborators) that already happens on main, please link this two-client variant there or in a new issue so it stays tracked until provenance or another collapse rule lands.

Smaller test notes

• Both headline cases reach their precondition with raw Yjs deletes (dropCommentItems). A case where the end goes through a collaborator's own deletes, as S9-12 does, would show the fix without the simulation.
• The hole case only exercises the comment author's own restore. A collaborator typing inside a comment written with a hole would cover the other-client path the description says the chain also fixes.

The changeset follows CONTRIBUTING.md (patch, a one-line [fix] summary, and a Verify: paragraph).

[meta-code-review]

must_fix: for a restore link of runChain, changeEnd returns the first item of the key its client wrote after it in clock order. When that restore's own write put no rule-5 null, that item is the null opening the same client's next hole, which rule 5 (:1155-1157) says is no end. Another client's restore in front of that hole then writes a null right after it, and the hole author's undo leaves that null ending the comment early: main keeps aa Kil[c1] X o[c1] Q met[c1] Y er[c1] bb cc, this branch gives aa Kil[c1] X o[c1] Q m[c1] etY er[c1] bb cc (steps in the review comment). One direction: reject a candidate end that its client follows with a restore of the run's value after its own text, or bound changeEnd on restore links to that restore's own write.

[zurfyx]

Fixed in 83df52d: a candidate end that its client follows, in clock order, with its own text and a restore of the run's value opens a hole, not an end (opensHole), so no null is written after it. The review's test is in OwnRunRestoreEnd.test.ts ("a later write's hole is not a run end") and passes for a comment and for bold, in both client id orders.

[meta-code-review]

This body passes on main, so S9-12b is a regression this change introduces rather than an existing gap. Worth linking from #9575 (the four-client variant, with three nulls from two collaborators, that already fails on main) or a new issue so it stays tracked.

[zurfyx]

Accepted as a documented limit (rare, and it loses no text): the test.fails pin stays here, and a sentence in y.md's Limits covering it and #9575 comes with #9569. #9561, stacked on this PR, makes this case pass (its undo keeps the run ends of the text it removes) and turns the pin into a plain test.

[meta-code-review]

Thanks for the detailed write-up, the reproductions in both client-id orders, and for pinning S9-12b and the #9589 tie as test.fails with tracking issues. One regression needs a fix before this lands.

opensHole can take a format change's real end for a hole (packages/lexical-y/src/internal/Cursor.ts:219-247, used by restatedEnd at :722-726)

opensHole walks the candidate end's client's structs in clock order and returns true when that client's next item of the key carries the run's value after one block of text. Nothing checks that this text and that item belong to the null's own write, although the comment at :214-217 says the scan covers that write's structs only. When the candidate is the end of a format change, and its client later typed plain text and then applied the same format elsewhere (bold a word, type, bold another word), the scan runs across those writes and returns true: restatedEnd rejects the real end and the restore gets no null of its own.

That switches rule 5 off for its original case, a run another client opened, which main handles (the S7-24 cases in regressions/Formats.test.ts). AGENTS.md's Backwards Compatibility section asks to keep current behavior intact, so this case should keep working. This test, added inside the ids loop of OwnRunRestoreEnd.test.ts, passes on main and fails on this branch in both orders, with the bold running over the rest of the document on every peer:

// B bolds "Kilo", types plain text, bolds "cc", then undoes all three,
// while A types plain "X" inside "Kilo".
test(`a restore in another client's run keeps its end after that client wrote the value again (ids ${ids})`, async () => {
  const $bold = (from: number, to: number) => () => {
    const selection = $selectIn([0], from, to);
    selection.format = (selection.anchor.getNode() as TextNode).getFormat();
    selection.formatText('bold');
    $setSelection(null);
  };
  const t = await setup(
    () => $getRoot().append($p('aa Kilo bb cc dd'), $p('tail line')),
    {ids, prepare},
  );
  t.b.update($bold(3, 7));
  await t.sync();
  t.b.update(() => $insertPlainAt(10, ' zz'));
  await t.sync();
  t.b.update($bold(14, 16));
  await t.sync();
  t.offline();
  t.b.undo();
  t.b.undo();
  t.b.undo();
  t.a.update(() => $insertPlainAt(5, 'X'));
  await t.sync();
  await expectConverged(t.peers);
  // this branch: paragraph("aa KiX" "lo bb cc dd"{1}) / paragraph("tail line"{1})
  expect(t.a.describe()).toBe(
    'paragraph("aa KiX" "lo"{1} " bb cc dd") / paragraph("tail line")',
  );
});

The same happens without the undos when Kilo's bold opener and end are dropped the way your first case drops the comment's ( bb zz cc turns bold), and the same sequence also leaves this PR's own-run fix off (A bolds Kilo, types, bolds cc, then types inside Kilo).

One direction: in opensHole, accept the key's restore only when it sits right after the text the scan passed, in the document (walking left from it over format and deleted items reaches that text), so an item a later write put elsewhere no longer counts. Please add the case above, and the dropped-end variant, to OwnRunRestoreEnd.test.ts.

Already tracked, not blocking here: S9-12b and the ids [2, 1] tie with a collaborator's bold that starts at the run's end are pinned and tracked (#9589, #9575, #9561), with the Limits text coming in #9569.

[meta-code-review]

Must fix: nothing here checks that the text and the key's next item belong to the null's own write. For a format change's end whose client later typed plain text and then applied the same value elsewhere (bold a word, type, bold another word), this returns true, so restatedEnd rejects the real end and a collaborator's restore inside that run gets no null of its own. main writes one there (rule 5's original case), and on this branch the bold then runs over the rest of the document on every peer. Accepting the restore only where it sits right after the scanned text in the document (walking left over format and deleted items) fixes it; the reproducer is in the review comment.

[zurfyx]

Fixed in 5a34d5c, as suggested: the key's item now counts as the hole's restore only where it sits right after the text the scan passed (walking left from it over format items and deleted items reaches that text, followsText). OwnRunRestoreEnd.test.ts has your case, the dropped-end variant and the own-run variant, each in both client id orders. All six fail on b8c4175 and pass now. The 64-comment-id case still passes.

[zurfyx]

Update: superseded by ac2c143. A randomized run-sequence fuzz still found shapes the hole scan got wrong (187 of 1,000 seeds against 9 on main), so rule 5 is narrowed back to main's (runOpener and that opener's change end), with one change: a restore inside a run its own client opened is no longer left out. opensHole, followsText and runChain are removed. Your three cases still pass in both orders, the fuzz now fails exactly main's seeds (RunSequenceUndo.test.ts, seed 87 = #9599), and the two cases the removed machinery covered beyond main are pinned as expected failures (main fails them too).

[meta-code-review]

Thanks for the thorough write-up and for pinning every known limit with a tracking issue. The own-run end does fix the offline-return spread. One case needs attention before this can merge.

Undoing a single write inside your own comment can now spread the comment over the rest of the document (packages/lexical-y/src/internal/Cursor.ts:669, through collapseGap at line 990)

Because restatedEnd no longer skips runs the writer opened, the writer's restore puts a null right after its own comment's end. Suppose a collaborator who has already seen that write deletes past the end, and another comment's items fall in the gap that delete collapses. collapseGap keeps the new null, which is the key's last item, and deletes the comment's own end. Its rule for keeping an earlier same-valued item only applies when another client wrote that item. The author's concurrent undo then removes the null, so nothing ends the comment. main keeps the end here. With the harness from OwnRunRestoreEnd.test.ts, the case fails in both client-id orders:

// $p('aa Kilo bb cc dd'), $p('tail line')
t.a.update(() => void $addMarkID('c1', $selectIn([0], 3, 7)));  // A comments "Kilo"
t.b.update(() => void $addMarkID('c2', $selectIn([0], 8, 10))); // "bb" has another comment
await t.sync();
t.a.update(() => $insertPlainAt(6, 'X'));                        // one write: "KilXo"
await t.sync();
t.offline();
t.a.undo();
t.b.update(() => void $selectIn([0], 7, 8).removeText());        // B deletes "o"
t.b.update(() => void $selectIn([0], 7, 8).removeText());        // then the space
await t.sync();
// main:        "aa Kil[c1] bb[c2] cc dd" / "tail line"
// this branch: "aa Kil[c1] bb[c1,c2] cc[c1] dd[c1]" / "tail[c1] line[c1]"

Deleting bb instead of the space gives the same result. So does deleting bb cc when the second comment is on cc. This is one write, so S9-12b and the Limits sentence proposed in #9569 (one client's two writes, or two clients' writes) do not cover it.

Two directions keep the end beside the new null. One is a collapse rule like 89e03fd's, which keeps each client's first same-valued item. The other is to also treat a same-client item from another write (for example, one with a non-adjacent clock) as protected at line 990. The PR description notes that 89e03fd brought back the offline spread in one session, so this is your call. If this case is accepted as a limit instead, please pin it beside S9-12 (OwnRunRestoreEnd.test.ts:254) with an issue and add it to the Limits text.

Optional, non-blocking:

• The comments at Cursor.ts:539-542, 637-646 and 1128-1131 still say rule 5 applies to a run "another client's change opened". OwnRunRestoreEnd.test.ts:326-329 still describes the removed hole scan.
• S9-12b and the #9589 tie are documented as accepted. Their Limits text lives in #9569, so it would be good to land that together with this change.
• The PR description still describes runChain and the original four-test plan. AGENTS.md asks the description, which becomes the commit message, to carry the real Before and After output of the final change.

[meta-code-review]

With the own-client exemption gone, a restore inside the writer's own comment puts a null right after the comment's end. If a collaborator who saw that write deletes past the end with another comment's items in the gap, collapseGap keeps that null (the key's last item) and deletes the end: its same-value rule at line 990 protects only another client's item. The writer's concurrent undo then removes the null, and the comment runs on over every later word and line. main keeps the end. The review comment has a reproduction in both id orders (comment on Kilo and on bb; A types X inside Kilo; A undoes while B deletes o, then the space).

[zurfyx]

Thanks: confirmed, and it is the third regression against main this extension of rule 5 has had. The PR is parked as a draft; the "Parked (10/30)" section at the top of the description covers this case (one write, a delete past the end collapsing a gap that holds another comment's items, collapseGap keeping only another client's same-valued item), the two earlier regressions, and what a redesign needs (a provenance marker for the end a restore relies on, or a different approach to S9-5). The cases, this one included, move to main as tests in #9605, with the ones main fails as expected failures.

[meta-code-review]

One null per end is enough here only while the run's own items are the gap's last units. With a comment on the next word, a single write is enough to lose the end: A undoes X while B deletes o and the space, and the comment spreads. Could that case sit beside this one, either as a test or as a pinned test.fails with an issue?

[meta-code-review]

Nit: this comment, the rule 5 text (1128-1131) and insertNegatedFormats' comment (539-542) still say the run was opened by another client's change. Since this PR, rule 5 also applies to the writer's own runs.