fix(ai): surface real HTTP error responses instead of "No response received"

[ImIvanGil]

Problem

When the AI panel's request fails for any reason that returns a small non-streamed JSON error body (vs. a streamed SSE response), users see the generic message:

"No response received from the API."

…regardless of what the actual error is. This is the most common failure mode and the most opaque.

Concrete examples of errors that get hidden:

Real cause	What server returns	What user sees
Invalid API key	{"error":{"message":"Incorrect API key provided: sk-***"}}	"No response received"
Wrong model name	{"error":{"message":"The model 'foo' does not exist"}}	"No response received"
Invalid temperature for Kimi thinking	{"error":{"message":"invalid temperature: only 1 is allowed for this model"}}	"No response received"
Quota / rate limit	{"error":{"message":"You exceeded your current quota..."}}	"No response received"
Wrong endpoint URL	Any non-SSE error body	"No response received"

This makes debugging custom providers, network issues, and key misconfiguration enormously harder than it needs to be. The errors are perfectly actionable — they're just being dropped.

Why it happens

curlProcess.stdout is a SplitParser that yields lines to currentStrategy.parseStreamChunk. The stream parser correctly ignores anything that isn't data: ..., so a JSON error body is silently dropped. When curl exits 0 (no network error) and responseBuffer is empty, the existing branch in onExited shows the generic placeholder.

The error body is in stdout the whole time — it just never goes anywhere.

Fix

Capture stdout into a side buffer on curlProcess and, in the empty-buffer branch, try to parse it as a typical OpenAI-style error envelope before falling back to the generic message.

 Process {
     id: curlProcess
+    property string rawStdoutBuffer: ""

     stdout: SplitParser {
         onRead: data => {
+            curlProcess.rawStdoutBuffer += data + "\n";
             let result = root.currentStrategy.parseStreamChunk(data);
             ...

+function extractApiError(raw) {
+    if (!raw || !raw.trim()) return "";
+    try {
+        let json = JSON.parse(raw.trim());
+        if (json && json.error) {
+            if (typeof json.error === "string") return json.error;
+            if (json.error.message) return json.error.message;
+        }
+    } catch (e) {}
+    return "";
+}

 onExited: exitCode => {
     ...
     if (root.responseBuffer === "" && root.currentChat.length > 0) {
         ...
+        let apiErr = curlProcess.extractApiError(curlProcess.rawStdoutBuffer);
+        newChat[newChat.length - 1].content = apiErr
+            ? "API Error: " + apiErr
+            : "No response received from the API.";
         ...
     }

Buffer is reset alongside responseBuffer at the end of each request.

Behavior

• Happy path (streamed response): unchanged. responseBuffer fills, error branch never runs.
• Streamed error chunk ({"error":...} inside data: ...): unchanged — still handled by parseStreamChunk via result.error.
• Network failure (curl exitCode != 0): unchanged — shows existing "Network Request Failed: ..." from stderr.
• JSON error body in stdout with curl exit=0: new path — extracts and surfaces the real error message.
• Empty stdout / unparseable stdout: falls back to existing "No response received" placeholder (no regression).

Tested

Reproduced and verified each of the four examples in the table above. Before: every one of them showed "No response received". After: every one shows the real provider message prefixed with "API Error: ".

Diff stats

modules/services/Ai.qml | 35 +++++++++++++++++++++++++++--------
1 file changed, 27 insertions(+), 8 deletions(-)

Related

5th in the series of Ambxst fixes. Related PRs:

• fix(launcher): drawer launches Terminal=true apps via xdg-terminal-exec #174 — fix(launcher): drawer launches Terminal=true apps
• fix(icons): resolve window icons via StartupWMClass desktop entry field #175 — fix(icons): resolve icon via StartupWMClass
• feat(ai): wire Config.ai.extraModels for user-defined OpenAI-compat providers #176 — feat(ai): wire Config.ai.extraModels
• feat(ai): support thinking/reasoning models in OpenAI-compatible strategy #177 — feat(ai): thinking/reasoning models support

This one is independent of the other AI PRs but massively improves the debugging experience for all of them. Without it, users debugging custom providers / thinking models / new API keys are flying blind. With it, they get the provider's own error message in plain text.