[chat] Cap markdown input length to avoid a render-thread freeze#23008
Open
Anexus5919 wants to merge 2 commits into
Open
[chat] Cap markdown input length to avoid a render-thread freeze#23008Anexus5919 wants to merge 2 commits into
Anexus5919 wants to merge 2 commits into
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Deploy previewBundle size
Check out the code infra dashboard for more information about this PR. |
Contributor
Author
|
@hasdfa Kindly have a review on this pr. Thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #22821
A large/dense markdown message freezes the render thread because
renderMarkdownfeeds the text straight intomarkdown-to-jsx, whose inline parser is super-linear and runs synchronously during render, with no input bound. Message bodies are effectively unbounded and attacker-influenceable (LLM output, a compromised backend/proxy, prompt injection, or a long paste), so a single large message can block the tab ('**a**'.repeat(16000)≈ 78 KB → ~2 s freeze, scaling quadratically).This adds a defense-in-depth input-length cap in
renderMarkdownand its streaming sibling: pastMAX_MARKDOWN_LENGTH(50 KB) the text is rendered as plain text (no truncation — all content stays visible) instead of being parsed. Realistic prose stays well under the cap and is unaffected; only pathological/oversized input degrades to plain text.This is Layer 1 (the safety backstop) of the layered plan discussed on the issue. It closes the single-render freeze with the smallest possible diff. The streaming-smoothness layers (per-block cap, block-level memoization, and
startTransitionduring streaming) are a planned follow-up and can be folded in here or shipped separately, per the maintainer's preference.Changelog
Bounded the Chat markdown renderer so a very large message body is rendered as plain text instead of freezing the render thread.