Skip to content

fix(tui): batch streaming part deltas to keep TUI responsive during fast streams#36045

Closed
YayoRazo wants to merge 1 commit into
anomalyco:devfrom
YayoRazo:fix-tui-delta-batching
Closed

fix(tui): batch streaming part deltas to keep TUI responsive during fast streams#36045
YayoRazo wants to merge 1 commit into
anomalyco:devfrom
YayoRazo:fix-tui-delta-batching

Conversation

@YayoRazo

@YayoRazo YayoRazo commented Jul 9, 2026

Copy link
Copy Markdown

Issue for this PR

Closes #36043

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Every message.part.delta SSE event was applied to the Solid store synchronously (packages/tui/src/context/sync.tsx), so each streamed chunk triggered reactivity and a re-render of the growing text part. Models with high chunk rates (GLM in my case) saturate the render loop, and queued input — scrolling in particular — stalls for several seconds, even in a brand-new conversation.

The fix accumulates deltas per part field in a small buffer and flushes them together every 40ms inside a single batch(). Why the final state is unchanged: flushing applies the concatenated delta exactly where the per-chunk appends would have landed, and a message.part.updated snapshot drops any buffered deltas for that part before reconciling (the snapshot already contains that text, so applying them afterwards would duplicate it). Removed parts/messages are skipped at flush time, same outcome as the previous per-chunk path.

How did you verify your code works?

Screenshots / recordings

Not a visual change — behavior fix (scroll responsiveness while streaming).

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

Every message.part.delta event was applied to the Solid store
synchronously, so each streamed chunk triggered reactivity and a
re-render of the growing text part. Models with high chunk rates
saturate the render loop and queued input (scrolling) stalls for
seconds.

Deltas now accumulate per part field and flush together every 40ms
inside a single batch. A message.part.updated snapshot drops any
buffered deltas for that part before reconciling, so the final store
state is identical to the unbatched behavior.

Closes #36043
@YayoRazo YayoRazo changed the title fix: batch streaming part deltas to keep TUI responsive during fast streams fix(tui): batch streaming part deltas to keep TUI responsive during fast streams Jul 9, 2026
@YayoRazo
YayoRazo force-pushed the fix-tui-delta-batching branch from 80b4851 to 6986c32 Compare July 9, 2026 07:53
CreatorGhost added a commit to CreatorGhost/TheCode that referenced this pull request Jul 12, 2026
CreatorGhost added a commit to CreatorGhost/TheCode that referenced this pull request Jul 12, 2026
CreatorGhost added a commit to CreatorGhost/TheCode that referenced this pull request Jul 12, 2026
…ast streams (#24)

* fix(tui): batch streaming part deltas to keep TUI responsive during fast streams

Ported from upstream anomalyco#36045.

* fix(tui): don't drop buffered streaming deltas

Addresses Opus review of PR #24: a full snapshot dropped this part's buffered
deltas; now flush them into the store before the snapshot reconciles. Also flush
on stream completion (assistant message completed / session idle) so a stream
that ends on a delta isn't truncated, and clear the batching timer on manual
flush. Adds regression tests.
@YayoRazo YayoRazo closed this by deleting the head repository Jul 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TUI scroll freezes for seconds during fast-streaming responses (message.part.delta applied per-chunk with no batching)

1 participant