Fixes #9235.

The bug

Streamdown renders both the syntax highlighted code body and the Mermaid diagram through React.lazy inside its own <Suspense>, and it fetches those chunks the first time a reply contains a fence or a diagram, on whatever network the app has at that moment. A rejected dynamic import rethrows during render, and there was no error boundary between the thread and the router, so the throw landed in TanStack Router's CatchBoundaryImpl.

The result was not a missing code block. The whole of Studio was replaced by the router's "Something went wrong!" page, the assistant-ui runtime was unmounted with it, and the reply's own stream was left with nothing consuming it, so the generator stopped being pulled and the message never completed. The part of the reply that had already rendered went too.

Before and after, same experiment on both trees

Streaming reasoning-pane fixture at 12,000 characters, chromium, aborting exactly one request:

page.route("**/highlighted-body*", lambda route: route.abort())

The stream row is the one that matters. A boundary that saves the page while leaving the generator dead would pass a "does not crash" check and fail this one: the test here is that the reply CONTINUES ARRIVING past the fence and finishes.

It was also seen once with nothing injected, one run in twelve on firefox, same fingerprint, reported by the browser as TypeError: error loading dynamically imported module for the same chunk.

Note that pageerror never fires for this. React routes it to console.error and the router boundary swallows the throw, so a harness listening only for page errors records nothing.

What the fix does

MarkdownBlockBoundary wraps every markdown block. A block that cannot render degrades to its own source as readable text, with the fence scaffolding stripped and the language header kept, so a fence whose highlighter is missing is still the same characters in the same order. Deliberately not an error card and deliberately not blank: a reader who asked for a shell command needs the command.

Per block, so one fence losing its colours costs its own colours and nothing else; every other block in the same reply keeps rendering, and the runtime, thread and stream are all outside the boundary.

No retry, on purpose. React and the browser's module map both cache a rejected dynamic import (whatwg/html#6768), so re-importing rethrows without issuing a new request. On a streaming reply a boundary that resets from props would throw and catch on every frame and get nothing for it. SettingsPanelBoundary in studio/frontend/src/features/settings/settings-dialog.tsx independently reached the same conclusion for the same reason, and its comment already records the same class of failure: "Nothing above this root-mounted dialog catches, so unguarded that unmounts all of Studio rather than one panel."

Scope: one boundary covers the whole class

There are exactly two React.lazy imports in the reply render path, both from streamdown/dist/chunk-BO2N2NFS.js:

lazy(() => import('./highlighted-body-OFNGDK62.js'))   // every code fence
lazy(() => import('./mermaid-GHXKKRXX.js'))            // every mermaid diagram

Both are rendered inside StreamdownBlockContent, so the same boundary encloses both.

• The highlighted code body path is verified LIVE, by aborting that request and measuring the table above.
• The Mermaid path is verified STRUCTURALLY, not by abort: it is the same component under the same boundary. Stated plainly so nobody has to infer it.

Separately checked so that "one boundary is enough" is a bounded claim rather than a hope: @streamdown/math and @streamdown/mermaid contain no dynamic imports of their own, math is not lazy, and artifacts and images in a reply are not lazy. The app's other lazy imports are outside the reply, where settings panels already have SettingsPanelBoundary and the rest are route-level, where replacing the route is defensible.

Tests

Nine tests over the pure fallback plus the wiring. They do not assert "the app does not crash"; they assert that the reader still has the content: a degraded fence is the same characters, the same line count, the same leading whitespace (in python the indentation is the program), an unclosed fence still degrades because the failure happens mid-fence, and prose is handed back untouched rather than rendered as code.

16 assertions, every one of them individually killed by a mutation, 12 mutations run one at a time in a throwaway worktree.

Worth stating rather than smoothing: four of those mutations had to be ADDED after the first pass, because seven of the sixteen assertions were only dying behind an earlier assertion in the same test. A test stops at its first failure, so an assertion that never independently kills anything is decoration. That is a real result about the first draft of the test file, not a formality.

One existing test changed, and why it is not weakened

markdown-block-remount-on-complete.test.ts pinned the exact spelling memo(StreamdownBlockContent). memo is still the OUTERMOST wrapper here, so the property that test protects is unchanged: on a memo hit React skips the boundary and the block together, exactly as before. The pin was moved to the new exact spelling rather than loosened, and the reason is in the comment in the diff: a version with memo INSIDE the boundary would render one component per block per token, and no OUTPUT test could tell the two apart. That last clause is what justifies a spelling-pinned test existing at all.

CI

Four checks fail here that are not from this change: (Python 3.13), Frontend build + bundle sanity, Frontend unit tests (Windows) and Repo tests (CPU). They are main-side and fail identically across other open PRs; #9220 fixes them. queued-model-capabilities in the frontend suite also fails on pristine main and is covered by the same PR. Local gates on this branch: npm test 3,786 pass with that one pre-existing failure, npm run typecheck clean, npm run build clean, and eslint adds zero problems over the baseline for the touched files.

On the failure rate, so it is not misquoted

This was found by a performance comparison in which it occurred in 4 of 52 runs. That 8% is not a user-facing frequency: every one of those runs was against a vite dev server, the correlate is the test driver's own page.route("**/*") interception (4 in 52 with it, 0 in 24 across two probe designs without it, 1 in 12 when it was added back), a cold vite dependency optimiser was tested as an alternative explanation and ruled out at 0 in 12, and 40 of 40 production-build cells were clean across chromium at 1x and 6x, firefox and Playwright WebKit.

So the fetch failure itself is most likely a dev-server plus harness artefact. The consequence of a failed fetch is not, and the consequence is what this changes. A flaky network, a CDN 404 after a redeploy hitting every open tab at once, or Desktop shipping the same bundle under default-src 'self' with no network to fall back on all reach the same code path.

Two consequences of the fallback, stated here rather than found in production

Neither is a defect being hidden. Both are things a reviewer should be able to weigh without reading the diff twice.

The latch is positional, and a rewind can move it onto a neighbour. Streamdown keys blocks by index, `${useId}-${index}`, so the boundary instance at position N outlives whatever block happens to sit at position N. The boundary does not reset, deliberately, so a failure latches. If IncrementalMarkdownCache then rewinds and re-segments the document, which is what preprocessLaTeX closing a \(...\) or resolving a \[...\] makes it do, and the block count BEFORE N changes, the latched boundary renders a different block than the one that threw. That block shows as raw Markdown source rather than rendered Markdown. No content is lost, since a non-fence is handed back unchanged, and a renderGeneration bump remounts the subtree and re-attributes every latch correctly. It needs a chunk failure and a count-changing rewrite strictly behind it, so it is rare, and by then every fence in the reply is degraded anyway.

Designing around positional keys is not free: it is what closed PR 9073 after seven review rounds. Recording the behaviour is the cheaper trade here.

A degraded fence keeps its Copy and Download controls. It did not, at first, and the reason is worth recording because it is not where anyone would look. CodeBlockActions lives inside FenceBlock, so a boundary that wraps the whole block unmounts the copy and download bar along with the fence that threw, and a completed SVG fence loses its already-sanitized SvgPreview too. That is the wrong trade at the wrong moment: a reader whose block did not render is a reader about to copy it out and read it elsewhere.

So Block, the only thing in a block that loads code at render time, has a narrower boundary of its own inside the wrapper that carries the controls, which makes the controls its siblings rather than its descendants. That alone was not enough, and only a browser measurement showed it. getCodeFence needs the CLOSING fence, so a fence that is still arriving has none and falls past the fence branch to the bare Block at the end of StreamdownBlockContent. That is the render that first asks for the highlighter, which is exactly when it fails. With that route unguarded the whole-block boundary caught it and latched, so the completed fence never re-entered FenceBlock and the controls never mounted: on a streamed reply the narrower boundary was unreachable and the document was identical to the one without it, 1,350 elements and zero copy buttons either way. Mermaid escaped only by accident, because it shows a placeholder while incomplete and so defers its import until the block is complete.

Both routes are guarded now. Measured on production builds with the same abort, streamed at field cadence: 3 copy, 3 download and the SVG preview all survive, against 0, 0 and 0 before, the block count holds at 11 rather than dropping to 10, the copy button puts all 453 bytes of the fence on the clipboard and the download writes a 453-byte snippet.py. The console confirms which boundary fired: the renderer boundary 6 times, the whole-block boundary 0. Degraded, a fence ends as the same plain shell an unreached fence already shows, carrying the same data-streamdown attributes, and a Mermaid diagram degrades to its source with its copy button intact.

The healthy render is untouched by all of it, checked rather than assumed: with nothing aborted, this branch and main agree on all of 1,530 document elements, 11 blocks, 1,693 assistant characters, 112 highlight spans, 3 copy and 3 download buttons, 1 SVG preview, and the per-block heights and text lengths element by element.

This narrows what is REPLACED and never what is CAUGHT. The whole-block boundary stays exactly where it was, so a throw from a hook, a sanitizer or an artifact card still degrades the whole block rather than reaching the router. The two rungs compose: the inner fallback is an element built by the caller, so if it throws in turn it throws as the inner boundary's own output and the outer boundary catches it, landing on the behaviour that was already shipped.

Update: rebased onto current main, and two fallback parse fixes

The branch was from 18 August and no longer merged cleanly. It now carries current main. The only conflict was in markdown-text.tsx, where main's #9462 extracted the fence branch into a new FenceBlock and left const StreamdownBlock = memo(StreamdownBlockContent) alone, while this branch replaced exactly that line. The two changes are orthogonal and git only conflicted because they abut, so the resolution keeps FenceBlock in full and keeps the boundary-wrapped StreamdownBlock. It was resolved twice independently, in two worktrees, and both resolutions produced a byte-identical file.

The four red checks were inherited, not caused here, and the control is the main-branch run at this PR's own merge base: Backend CI 32141907885 and Frontend CI 32141907900 fail job for job with the same signatures, including (Python 3.11) passing alongside them. Main was broken by #9173 and fixed by #9189 and #9192 on 19 August, after this branch was cut.

Separately, two parse defects in the fallback itself, which matter because that path only ever runs once rendering has already failed:

• A closing fence may carry MORE characters than the opening one (CommonMark 0.31.2, "at least as many"), which is how a model closes a fence whose body contains a fence. The back-reference demanded an exact match, so a four-backtick close was shown as if it were the last line of the code.
• An empty fence closes on the line after it opens, and the closing run was being returned as the body, so ``` rendered inside the code block as though the model had written it.

Both are now scanned rather than matched, which also removes a quadratic backtrack: the old pattern put [^\r\n]* directly after `{3,}, and the two competed for the same backticks whenever an opening run had no line break after it. A 400,000 character run of backticks now parses in 2.1 ms.

Each fix has a regression test confirmed failing against the unfixed code first. npm test is 4,403 passing, up from 4,400 by exactly the three tests added, with npm run typecheck clean and eslint adding zero problems over main's own baseline for the touched files.