perf(web): coalesce streaming Markdown renders

[nateEc]

Closes #4074

Summary

• coalesce streaming assistant Markdown updates to a 50ms rendering cadence
• keep Markdown component identities stable while text deltas arrive
• flush the final response immediately without splitting whole-document Markdown semantics

Verification

• vp test run apps/web/src/components/ChatMarkdown.logic.test.ts apps/web/src/components/markdown-list-indentation.test.tsx apps/web/src/components/markdown-links.test.ts (27 passed)
• vp run --filter @t3tools/web typecheck
• targeted lint for the changed files (only pre-existing nested-component warnings)
• test-t3-app: streamed a live Codex response containing paragraphs, bullet/task lists, a table, and a fenced TypeScript block; all rendered after completion

---

Note

Low Risk
UI performance tuning in chat markdown rendering only; behavior change is limited to update cadence during streaming, with immediate flush when streaming stops.

Overview
Streaming assistant messages no longer trigger a full react-markdown parse on every token. While isStreaming is true, useStreamingMarkdownText applies the latest text on a 50ms cadence via streamingMarkdownRenderDelay, canceling superseded timers so rapid deltas coalesce.

ChatMarkdown now drives link metadata, inline-code file links, task-list marker offsets, and the memoized ReactMarkdown tree from that throttled renderedText. When streaming ends, the hook syncs immediately to the final text (no artificial delay on the completed message).

A small ChatMarkdown.logic helper plus unit tests cover interval math, including backward clock jumps.

^{Reviewed by Cursor Bugbot for commit a73ad50. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Coalesce streaming Markdown renders in ChatMarkdown to a 50ms interval

• Adds useStreamingMarkdownText hook in ChatMarkdown.tsx that throttles text updates during streaming to at most one render per 50ms, clearing superseded timers and recording render timestamps
• Adds streamingMarkdownRenderDelay util in ChatMarkdown.logic.ts that computes the non-negative remaining delay since the last render, clamping elapsed time to zero when the clock moves backwards
• ChatMarkdown now uses throttled renderedText for file-link extraction, inline-code extraction, task-list markers, and the memoized ReactMarkdown output; non-streaming renders sync immediately
• Behavioral Change: streaming ChatMarkdown no longer re-parses and re-renders on every incoming text value; output updates at most every 50ms while streaming is active

^{Macroscope summarized a73ad50.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 99527976-11c4-4004-9674-6ac5d821e8e1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a46d860c61e47a8f6ad2ff9b7334ae213d5ae908. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR changes an existing assistant-message path by automatically suppressing Markdown parsing and DOM updates between 50 ms snapshots during streaming. Since this gate controls when substantial rendering work occurs without an operator choice, the runtime behavior merits human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[nateEc]

Final refresh on current main: 325e1fe9a.

• Implementation range-diff is unchanged from the reviewed version.
• Focused Markdown tests: 65/65 passed.
• GitHub checks: 20/20 completed, 0 failures.
• Local web typecheck is blocked only by current-main electronPasskeys test typing errors outside this PR.
• Linux CPU and Markdown rendering repro instructions were sent to @mudit-loya.
• PR is mergeable and clean.

[nateEc]

@juliusmarminge @mudit-loya — this is ready for human review and Linux reproduction validation on 26ebe2fb7.

The current-main version coalesces streaming Markdown parsing to at most once every 50ms, while synchronously flushing the complete final response. It preserves current links, task lists, raw HTML, tables, and code-block behavior. The focused suite is 54/54, web typecheck and isolated browser streaming verification pass, and all CI/Bugbot/Macroscope checks are green (including Approvability and UI Consistency).

For review, the main tradeoff is the 50ms intermediate-render cadence; final rendered output and stream-completion timing remain unchanged. A quick check against the original Linux high-CPU reproduction would be especially useful.

[mudit-loya]

@nateEc how can we test this fix?

[nateEc]

Thanks for offering to verify this. The useful comparison is the same one from #4074, using the same model and a response of roughly the same length:

1. Build/run this PR branch (nateEc:codex/fix-4074-streaming-markdown-cpu) on Linux.
2. In a fresh thread, stream a reply containing several paragraphs plus a fenced code block, task list, table, and nested list. Record the peak combined CPU for the T3 renderer and GPU helper in htop; repeat once.
3. Repeat the same prompt in a long thread with many already-rendered messages, again recording two peak samples.
4. Confirm the final Markdown is complete after streaming: especially blank lines inside code fences, task-list checkboxes, tables, nested lists, and reference-style links.

The primary success signal is that long-thread streaming no longer scales sharply above the fresh-thread result (the original report was roughly 76%/65% versus 35%). The fresh-thread baseline may still be non-trivial; this PR specifically targets the per-token full reparse. Please include the T3 commit, Linux/desktop version, and the four peak samples when reporting back.

[nateEc]

@juliusmarminge Ready for another review on 325e1fe9a. Rebased onto current main; implementation range-diff is unchanged, 65/65 focused Markdown tests pass, and all 20 GitHub checks completed with 0 failures. Linux CPU/rendering repro instructions were sent to @mudit-loya. Mergeable state is clean.

Dismissing prior approval to re-evaluate 6497047

[nateEc]

@juliusmarminge Rebased onto the latest main; the focused ChatMarkdown suite passes and the current CI is green. Could you take a human review when you have a moment?

[nateEc]

Rebased onto current main in ac980ca. The resolution retains the current link-target handling and applies the streaming Markdown render coalescing unchanged.

Verified: vp test run apps/web/src/components/ChatMarkdown.logic.test.ts apps/web/src/components/ChatMarkdown.test.tsx apps/web/src/components/ChatMarkdown.workspace-images.test.tsx (73 passing), vp fmt --check for the changed files, and the focused Web type check.

[nateEc]

CI note: the only failing Test assertion is the unrelated bundled-dev Vite readiness race in apps/web/src/bundledDev.test.ts (expected JavaScript, received HTML). It reproduces identically across these rebased PRs and is covered by maintainer PR #9558 (test(web): fix flaky startup and Tailwind tests). I did not duplicate that shared CI repair into this focused PR; the PR-specific targeted tests and type checks passed locally.

[nateEc]

Follow-up: #9558 is now in main, and this PR has been rebased onto that repaired CI baseline. Its targeted tests were rerun successfully; the updated commit is now awaiting the fresh CI result.