Repository navigation
Something went wrong. - resolveLanguage: "txt" not found in bundled or custom languages #210
Description
Activity
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
txtas the language.Problem
If a chat message contains a fenced code block like:hello
the renderer extracts
txtfrom 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 languagesand 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.
txtis 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 thev0.0.2source tag as well.Suggested fix
- Normalize markdown fence languages before sending them to the highlighter.
- Map plain-text aliases to a safe fallback.
- Add a runtime fallback so unsupported fence languages render as plain text instead of crashing.
Suggested alias handling:
txt->textplain->textplaintext->text- empty/undefined ->
text
Recommended behavior:
- try highlighting with the normalized language
- if that still fails, fall back to
text
Expected result
```txtblocks 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
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.- added a commit that references this issue
on Mar 7, 2026 - added a commit that references this issue
on Mar 14, 2026 - added a commit that references this issue
on Jun 17, 2026 - added a commit that references this issue
on Jul 7, 2026 - added a commit that references this issue
on Aug 18, 2026
Windows 11
2 projects added
2 chats in single project started
then it crashed