I updated yesterday[1] and now there are a lot of errors in the logs: Discourse AI: structured output response was not valid JSON, falling back to best-effort parsing (311 bytes) I inspected the HTTP response and it had no issue. Then I tried the text with rails console: ... discourse(prod)> p = JsonCompleter.new => # p.parse text => {"spam" => false, "reason" => "..."} discourse(prod)> p.parse DiscourseAi::Utils::BestEffortJsonParser.escape_control_characters(text) (discourse):14:in ' ': unexpected token "\\" (JsonCompleter::ParseError) it turns out that Discourse escaped line feed characters before parsing[2], causing the error. [imagen] Commits · discourse/discourse A platform for community discussion. Free, open, simple. - Commits · discourse/discourse ↩︎ code, introduced by pr#41716 ↩︎

Fix is here: FIX: Preserve whitespace in streamed JSON (#42339) main ← jsonfix merged 07:31AM - 05 Aug 26 UTC (UTC) [imagen] SamSaffron +130 -15 Escape control characters only within JSON string values so pretty-printed forma…tting remains intact. Retain lexical state across streaming chunks to correctly handle split strings, escapes, and control characters.

[imagen] lilydjwg: and now there are a lot of errors in the logs: That is a warning, not an error. That said, I’m moving that to INFO log level, as people keep getting worried about these :face_exhaling:

[imagen] Falco: That is a warning, not an error. Well, technically true, but it indicates a bug in the code. The fallback works so no error is raised, but it is better to fix the source instead of moving it to INFO level to cover up, isn’t it? JSON allows line feed charaters as whitespace but doesn’t allow escape sequences outside strings; the escape function however escapes it. To fix it, you can change to escape only ASCII characters 0x0 to 0x1f inclusive according to the JSON spec. (I don’t know how to write it in Ruby so no PR.)

To illustrate, the following is valid JSON: { "key": "value" } The following is an escaped one, which is invalid and causing the issue: {\u000a "key": "value"\u000a}

llama-server -hf mradermacher/Qwen3-4B-Instruct-2507-GGUF:Q4_K_M

A 4B model is going to struggle to comply, they are getting better, but this is certainly on the older side. If you are going 4B I probably would recommend something more recent … try Qwen 3.5-4B or Gemma 4 E4B.

I believe that llama.cpp forces the schema by picking only tokens that conforms to it. I also captured a response with tcpdump and checked that the returned response is valid JSON. It contained spaces and line breaks outside strings however (i.e. it is a pretty-printed JSON), and those line breaks were escaped by Discourse, making it invalid (I checked it in rails console). I’m using the spam detection feature btw.

Discourse AI: la respuesta de salida estructurada no era JSON válido

Soporte del producto

sam (Sam Saffron) 5 Agosto, 2026 05:27 5

¿Qué LLM estás utilizando?

Tema		Respuestas	Vistas
Translation silently truncated when JSON stream parsing breaks (no error raised) Bug ai , dynaloc	2	306	14 Julio 2026
JSON API parsing error, single quotes used for errors like "['BAD CSRF']" Bug	2	1452	16 Marzo 2017
Error on ask.discourse.com: SyntaxError: Unexpected end of JSON input Bug ask-discourse	3	240	10 Julio 2025
AI translations errors Bug ai	10	527	10 Mayo 2026
Llm_tagger: Failed to parse JSON response for post 30871: unexpected character (after tags) at line... [parse.c:706] in '{"tags":":[" Bug automation , ai	8	305	26 Septiembre 2025

Discourse AI: la respuesta de salida estructurada no era JSON válido

Temas relacionados