Environment
Jmix version: 3.0
Bug Description
When a generated JPQL query fails validation, the data-load subsystem asks the model to repair it and expects a bare JSON object in response. Some models wrap the JSON in a Markdown code fence (```json ... ```) despite the prompt asking for no Markdown. The add-on cannot parse such a response and the whole tool call fails with a technical exception instead of a structured result.
The exception text, which includes the model's full response with the generated JPQL, is returned to the chat model as the tool result. This contradicts the intended behavior where the model receives only structured validation issues and guidance, and never raw technical errors
The same parsing is used when a data-load query is generated for a non-chat consumer (for example, the Reports LLM band), so that path is affected as well.
Steps To Reproduce
- Configure the AI Tools add-on with a model that tends to wrap JSON in code fences (observed with a Gemini-family model).
- In the AI chat, ask for an attribute that does not exist on an entity, for example "show the displayName of the first User" when
User has no displayName property.
- The generated query fails validation and a repair attempt is made.
Current Behavior
The repair attempt throws `IllegalStateException: Cannot parse LLM response as JSON: json { ... "jpql": "SELECT u.displayName FROM User u", ... }. The chat model receives this text as the tool result. Whether the user sees the technical details or the JPQL then depends only on how the particular model treats the error text.
Expected Behavior
- A repair response wrapped in Markdown code fences, or surrounded by extra text, is parsed as long as it contains a valid JSON object.
- If the repair response still cannot be parsed, the repair is treated as unsuccessful: the tool returns the original validation issues and guidance as a structured result, and the model can retry or report the problem to the user in a non-technical way. The technical details stay in the server log.
- The same applies to the non-chat generation path used by other consumers of the data-load subsystem.
Environment
Jmix version: 3.0
Bug Description
When a generated JPQL query fails validation, the data-load subsystem asks the model to repair it and expects a bare JSON object in response. Some models wrap the JSON in a Markdown code fence (
```json ... ```) despite the prompt asking for no Markdown. The add-on cannot parse such a response and the whole tool call fails with a technical exception instead of a structured result.The exception text, which includes the model's full response with the generated JPQL, is returned to the chat model as the tool result. This contradicts the intended behavior where the model receives only structured validation issues and guidance, and never raw technical errors
The same parsing is used when a data-load query is generated for a non-chat consumer (for example, the Reports LLM band), so that path is affected as well.
Steps To Reproduce
Userhas nodisplayNameproperty.Current Behavior
The repair attempt throws `IllegalStateException: Cannot parse LLM response as JSON:
json { ... "jpql": "SELECT u.displayName FROM User u", ... }. The chat model receives this text as the tool result. Whether the user sees the technical details or the JPQL then depends only on how the particular model treats the error text.Expected Behavior