🤖 Chunked streaming rows: bound oversized blocks without a transition, narrow document-scoped detection #5664

Activity

1. ThomasK33

   added

   backlog

   on Oct 5, 2026
2. ThomasK33

   self-assigned this

   on Oct 5, 2026
3. ThomasK33 commented on Oct 5, 2026

   

   ThomasK33

   on Oct 5, 2026

   MemberAuthor

   More actions

   Two more items from the final independent check on #5663 (head 987acf5), both limited to rows above 20k chars that remount mid-stream:

   3. A sealed chunk is not always final for loose lists. parseMarkdownIntoBlocks returns the blank lines between blocks as their own block ("- a\n\n " → ["- a", "\n\n "]), so a list item can be sealed before its continuation arrives. Example: intro\n\n- item one\n\n continued item text\n- item two ends as the chunks "- item one", " continued item text\n" and "- item two", while one render gives one list. The continuation renders outside the list until the row remounts. No text is lost. Proposed fix: seal a group only when the block after it is more than blank lines and the group ends with a newline. Add a loose-list case to the equivalence test.
   4. The oversized-chunk comment overstates the bound. MarkdownCore uses streaming mode only when parseIncompleteMarkdown && !renderSynchronously. Sealed chunks, and all chunks after completion, have parseIncompleteMarkdown=false, so a block above 20k renders statically and synchronously once later text seals it. On main the same row pays a larger synchronous render at completion, so the task moves earlier. Fix the code comment at ChunkedStreamingMarkdown.tsx (the renderSynchronously line), and either bound this case or test the mode that actually runs instead of the mocked data-sync prop.

   ---

   Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $21.66
4. ThomasK33 commented on Oct 5, 2026

   

   ThomasK33

   on Oct 5, 2026

   MemberAuthor

   More actions

   Perf owner decision: hold until the #5655 fix lands, then re-measure, then dispatch. The perf owner decides after the re-measurement.

   Reason: #5655's root cause is remend running over the whole reply on every frame (quadratic, 47 ms per call at 60k). Its fix repairs only the trailing block in MarkdownCore, which the chunked rows from #5663 also use. That changes this issue's first item, oversized-block starvation while live, directly. A fix designed now would target costs that are about to move.

   After the #5655 PR merges, re-run the #5663 dense benchmarks plus an oversized single block (one 20k+ code fence, one 20k+ table) on main. Dispatch only the items that still fail the #5647 targets. The doc-scoped regex fallback and loose-list sealing are correctness items, not perf. They can go to the coordinator at that point.

   ---

   Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
5. yermakoffivan

   added a commit that references this issue on Oct 5, 2026

   🤖 fix: show long streaming replies at once when you switch back to th…

   ...

   90ff8ca
6. ThomasK33 commented on Oct 5, 2026

   

   ThomasK33

   on Oct 5, 2026

   MemberAuthor

   More actions

   Measurement on main 31616698f2 (after #5667), 5 runs per case, loopback fixture at 900 chars/s, production renderer:

   • Single huge block, fresh stream (perf: a live reply that is one huge markdown block (list, paragraph, table) still stops growing while streaming #5666): still stalls for every block kind. At 20k chars the row stops growing for 4.5–8 s (58–80% of the text on screen at stream end). At 60k it stops for 10–55 s (16–82% on screen), with main-thread tasks up to 0.5–1.5 s.
   • Why: inside one huge block, both the markdown repair and the block render scale with the whole reply. Per frame at 60k: repair 313 ms (list), 401 ms (paragraph), 454 ms (code), 15 ms (table); render 328 / 332 / 41 / 1,243 ms. A fix must bound both: repair from a fixed tail inside the last block, and render in sub-block ranges (items, rows, lines).
   • Switch-back (🤖 Chunked streaming rows: bound oversized blocks without a transition, narrow document-scoped detection #5664 item 1): single-block rows at 30k/50k show no text, or text that does not grow, for the whole 8 s window.
   • 🤖 Chunked streaming rows: bound oversized blocks without a transition, narrow document-scoped detection #5664 item 2: confirmed. [^…] inside code makes the row fall back to one whole render at completion. Output stays correct.
   • New defect from 🤖 fix: show long streaming replies at once when you switch back to their chat #5663: the chunker splits one loose ordered list into 4 <ol> lists, and the split stays after completion. A frame that ends in \n\n301 before the . arrives ends the list, and the chunker seals that chunk. A fix PR is in progress (it will say Refs #5664).

   Next: the loose-list fix lands first. The single-block design (#5666 + #5664 item 1) follows in a separate PR, because it touches the same files.

   ---

   Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
7. ThomasK33 commented on Oct 5, 2026

   

   ThomasK33

   on Oct 5, 2026

   MemberAuthor

   More actions

   The loose-list split is fixed in #5668 (d91c3079f3). The fix had two causes and two parts. Both regression tests fail on main and pass after the fix:

   1. Chunker: a tail made only of blank lines or bare digits (a list marker still arriving) no longer seals the list chunk before it.
   2. Stale render: while streaming, the open chunk now remounts when it is sealed and when the stream ends. Streamdown kept the tight-list render of the first item, which caused the missing <p>. Sealed chunks keep their keys and their memo.

   Fixture after the fix (2 runs): 1 <ol>, 319 of 319 items with <p>, and output identical to a single render.

   Still open on this issue:

   • Item 1 (switch-back for a single huge block), together with perf: a live reply that is one huge markdown block (list, paragraph, table) still stops growing while streaming #5666. This is the next lane.
   • Item 2 ([^…] inside code triggers a whole render): not fixed. A correct fix needs code-span and escape parsing. A wrong strip would hide a real footnote, which is worse than one extra render.
   • New, minor: the remount at seal and at completion drops DOM state inside that one chunk, such as a text selection or a code block's "copied" state. While streaming, the open chunk can also show the tight-list render for a moment. For a final block close to 20k chars, the remount at completion can take more than 50 ms.

   ---

   Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
8. yermakoffivan

   added 2 commits that reference this issue on Oct 5, 2026

   🤖 fix: keep a loose list whole in chunked streaming rows (coder#5668)

   ...

   d91c307

   🤖 perf: cut a huge list in chunked switch-back rows at its items (cod…

   ...

   c5a0c61
9. ibetitsmike

   added

   investigationTriage: proposal / research / trackingTriage: proposal / research / tracking

   on Oct 9, 2026