fix(chat): parse long lines of unclosed brackets in linear time

[devswha]

Change

parseInline in src/lib/markdown.ts took quadratic time on one long line of openers that never close: [a, \(, _a or __a repeated. The chat parses every agent message with it while it draws, so a single such line (a log, a minified blob) froze the tab: about a minute or more per megabyte. It stayed under the 1 s bound the tests use at 48 KB, so nothing failed. #547 hardened this file against other shapes and left this one.

The cause was the single pattern searched over the whole line: from every opener it scans to the end of the line for a closer, fails, and starts again at the next opener.

Now the pattern is tried (sticky) only at places a mark can start. For the three openers whose closer may be far away, it is tried only when a closer is there, and each closer is searched for once and reused for every opener before it:

• \( needs a \) before the next line break.
• [ needs ]( at the first ], and a ) ending the address.
• __ and _ need their closing __ or _ on the line. A __ that only a _ can close is tried as the single-underscore form alone.

The pattern itself is unchanged, so the marks found are the same. While measuring I found two more quadratic shapes with the same cause, [a](b and __a b_ repeated; the same change covers them.

The change is in src/lib/markdown.ts only (a new exported generator inlineMarks that parseInline loops over; the loop body is untouched).

Validation

Time to parse one line, parseMarkdown, main (f8f09d1) against this branch:

Line	Bun, main, 192 KB	Bun, branch, 1 MB	Chrome 151, main, 192 KB	Chrome 151, branch, 1 MB
[a repeated	4003 ms	41 ms	9374 ms	54 ms
\( repeated	8069 ms	25 ms	4027 ms	20 ms
_a repeated	4936 ms	19 ms	3592 ms	20 ms
__a repeated	8952 ms	35 ms	9159 ms	29 ms
[a](b repeated	1603 ms	31 ms	5063 ms	27 ms
__a b_ repeated	2140 ms	91 ms	1696 ms	90 ms

Main was not timed at 1 MB for every shape: [a at 1 MB took 111 s there, in the new test. On the branch 8 MB takes 138 to 744 ms in Bun, so the growth is linear.

• New test in src/lib/markdown.test.ts: each of the four shapes at 1 MB parses within the file's 1 s bound and stays plain text, the two extra shapes parse within it, and for 66,430 short lines inlineMarks finds exactly what one search with the pattern finds. Run against main's parser it fails (Expected: < 1000, Received: 111111); with a closer looked for one place too far, the comparison fails.
• Output compared with main's parser outside the suite: 8,012,554 inline inputs (exhaustive short lines over six alphabets, plus random lines with links, URLs, code, CJK, emoji and line separators, each with and without links) and 60,000 random documents through parseMarkdown. No difference.
• HERDR_TEST_MODE=unit bun test ./src/lib/markdown.test.ts: 41 pass, 0 fail.
• bun run check fast: generated types fresh, typecheck, build, unit tests 1700 pass, 0 fail.

No UI or contract change, so no screenshot or contract test.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: devswha/herdr-web-ui/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 62620297-c1dc-43d8-aff5-059c2086f4ec

📥 Commits

Reviewing files that changed from the base of the PR and between 4e654ac and 882669f.

📒 Files selected for processing (1)

• CHANGELOG.md

🚧 Files skipped from review as they are similar to previous changes (1)

• CHANGELOG.md

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 5 remain after this review.

---

📝 Summary

Summary by CodeRabbit

• Bug Fixes
  • Chat reading no longer freezes when messages contain long runs of unclosed brackets, inline-math markers, or underscores. This improves responsiveness when viewing malformed Markdown, including very large amounts of affected text, while keeping the displayed message appearance unchanged.

Walkthrough

Inline Markdown parsing now uses inlineMarks to find marker matches instead of a global matchAll scan. Regression tests check match equivalence and completion time for long or malformed inputs.

Changes

Markdown Inline Scanning

Layer / File(s)	Summary
Scanner and parser integration src/lib/markdown.ts	inlineMarks scans candidate markers and checks closers with cached forward searches. parseInline consumes its matches.
Scanner regression tests and changelog src/lib/markdown.test.ts, CHANGELOG.md	Tests compare scanner matches with the previous regex and check long or malformed inputs. The changelog records the reported rendering-time change.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix · Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 88266

No unresolved merge-blocking issue is identified. Merge after normal checks.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the primary fix: parsing long lines with unclosed brackets in linear time.
Description check	✅ Passed	The description includes complete Change and Validation sections. It explains the failure, implementation, regression coverage, performance results, and why screenshots and contract tests are not appl…
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 2 files. (1 skipped: 1 …
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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

[devswha]

Independent review (merge-own lane).

Classification: serious bug fix. One long line of unclosed [, \(, _ or __ froze the chat tab for a minute or more per megabyte, and agents print such lines in logs and minified output.

What I checked:

• inlineMarks tries the unchanged marker pattern (now sticky) only at positions where an alternative can start (opener covers every alternative's first characters). For \(, [ and _/__ it tries the pattern only when the closer exists before the line ends. Each closer search goes through next(), which caches the last hit, and every call passes a non-decreasing from, so each closer is found once per line. The conditions match the regex: the formula needs \) at or after start + 3 before a .-breaking character. The link needs a non-empty label, ]( at the first ]/newline, and a non-empty target ended by ). A __ with no closing __ is tried as the single-_ form only.
• Mutations, each run against the new equivalence test: mathClose(start + 4) fails it, and so does emphasisClose(start + 3). labelEnd(start + 2) and strongClose(start + 4) stay green, but they change only which positions skip the full pattern, not the result: the sticky marker re-checks the label, and the emphasis path yields the same span. So these are not coverage gaps.
• Codex (gpt-6.1-sol, xhigh, adversarial, read-only) found no material issue. It compared 400,000 malformed and Unicode inputs with the old scanner and found no difference.
• The CHANGELOG entry sits under ## [Unreleased] / ### Fixed, after #572, with its PR link.

What I ran:

• HERDR_TEST_MODE=unit bun test ./src/lib/markdown.test.ts: 41 pass.
• Updated the branch with main (merge, CHANGELOG conflict with #572 resolved by keeping both entries; now 4e654ac). bun run check fast on 4e654ac: 1700 pass, 0 fail.
• On 4e654ac, Integration and browser first failed at scripts/ui-regression.ts:604 ("the message sent before the snapshot is a live pending row"). That assertion is a known timing flake and is unrelated to markdown. One rerun of the failed job passed.
• main moved again (#563, CHANGELOG conflict) before the merge, so I updated once more to 882669f (CHANGELOG order #566, #572, #563, #574). bun run check fast: 1715 pass, 0 fail. Fast checks and Integration and browser are green on 882669f. There are no review threads, and CodeRabbit had no actionable comments.