Something went wrong. - resolveLanguage: "txt" not found in bundled or custom languages

[blonestar]

Windows 11
2 projects added
2 chats in single project started
then it crashed

[blonestar]

As probably not allowed to push and create a PR lets go this way.

I tracked this down and the crash is caused by markdown code fences using txt as the language.

Problem
If a chat message contains a fenced code block like:

hello

the renderer extracts txt from the markdown fence and passes it directly into the Shiki highlighter. In the current implementation, that value is not normalized and there is no safe fallback for unsupported language ids.

That leads to this runtime error:

resolveLanguage: "txt" not found in bundled or custom languages

and the chat view / renderer crashes.

Why this happens

In apps/web/src/components/ChatMarkdown.tsx, the code fence language is taken from the markdown class name and used directly in the highlight path (getSharedHighlighter(...) / codeToHtml(...)).

This is unsafe because markdown content may contain aliases or unsupported language ids. txt is a common fence label, but this highlighter setup does not accept it as-is.

Why this also affects the desktop release

This is in the shared React chat renderer, so the packaged desktop app is affected too. I hit this in the Windows installer release (v0.0.2), and the same issue is present in the v0.0.2 source tag as well.

Suggested fix

1. Normalize markdown fence languages before sending them to the highlighter.
2. Map plain-text aliases to a safe fallback.
3. Add a runtime fallback so unsupported fence languages render as plain text instead of crashing.

Suggested alias handling:

• txt -> text
• plain -> text
• plaintext -> text
• empty/undefined -> text

Recommended behavior:

• try highlighting with the normalized language
• if that still fails, fall back to text

Expected result

• ```txt blocks no longer crash the app
• unknown/unsupported fence languages render as plain text
• supported languages still highlight normally
• ideally add a regression test for txt / plain-text aliases

[mwolson]

I dug into this locally and got to what I think is the same core answer the reporter is pointing at: the crash isn’t really about any one specific language label like txt, it’s that markdown code highlighting can currently throw when the fence language is unsupported, and that exception bubbles up far enough to break chat rendering.

What seems robust is:

• keep trying Shiki for supported languages
• but if highlighter init or codeToHtml(...) throws for any reason, render a normal plain <pre><code> block instead
• log a warning so the failure is still visible in devtools, but don’t let highlighting take down the message UI

That avoids having to maintain ad hoc alias mappings and should cover txt, conf, and any other unknown fence label.

If it’s helpful for an agent, here’s a prompt that should be close to the intended fix:

In `apps/web/src/components/ChatMarkdown.tsx`, make markdown code block rendering resilient to syntax highlighting failures.

Requirements:

* Unsupported or unexpected code fence languages must never crash chat rendering.
* Keep syntax highlighting for normal/supported languages.
* If highlighter creation fails, fall back to rendering a plain `<pre><code>` block.
* If `codeToHtml(...)` fails, also fall back to a plain `<pre><code>` block.
* Log a warning when fallback happens, but do not throw.
* Per-language aliases may perhaps have a part in the eventual fix, but do be sure that this problem has a generic fix for resilience.
* Keep existing caching behavior for successful highlighted output.