Typed Mistral message.content chunks are ignored, causing 'No result' errors

[dtump]

Which version of integration_openai are you using?

4.5.1

Which version of Nextcloud are you using?

33.0.6.2, using the nextcloud:33.0.6-apache Docker image.

Which browser are you using? In case you are using the phone App, specify the Android or iOS version and device please.

Not browser-specific. Observed through the Nextcloud Assistant web interface, but the failure occurs in server-side response normalization.

Describe the Bug

When an OpenAI-compatible endpoint returns assistant message.content as a list of typed content chunks, integration_openai 4.5.1 ignores the content and can eventually report:

No result in OpenAI/LocalAI response.

I encountered this repeatedly with Mistral Small 4 (mistral-small-2603) through https://api.eu.mistral.ai/v1. The failures occurred in core:text2text:chatwithtools after an external MCP web-search tool had completed successfully. Both single and parallel tool-use cases were observed, so parallelism was not the cause.

The relevant parser in OpenAiAPIService::createChatCompletion() only accepts content when it is a string:

if (isset($choice['message']['content']) && is_string($choice['message']['content'])) {
    $completions['messages'][] = $choice['message']['content'];
}

Mistral's assistant-message schema permits content to be either a string or a list of typed chunks. Observed chunk types included:

• text
• reference
• thinking

Official schema references:

• AssistantMessage
• ContentChunk
• ThinkChunk
• DeltaMessage

Confirmed response metadata

I reconstructed one previously failed synthetic request and replayed it three times with the same model, messages, tools, n: 1, max_tokens: 5000, no extra parameters, and no explicit reasoning_effort.

All three requests returned HTTP 200, one choice, finish_reason: stop, no tool call, and no audio:

Replay	message.content	Chunk types	Parser result
1	string	n/a	accepted
2	array	alternating text and reference, ending in text	rejected
3	array	alternating text and reference, ending in text	rejected

This shows why the problem is intermittent: the same request can return either a string or typed content.

A separate public synthetic request using reasoning_effort: "high" returned a thinking chunk followed by a text chunk. Version 4.5.1 rejected that response as well. This was only a deterministic response-shape probe; I am not proposing reasoning_effort as a production setting or workaround.

No prompts, tool-result bodies, response text, credentials, user identifiers, or raw provider responses have been retained.

Tested local workaround for 4.5.1

I locally patched version 4.5.1 to:

• preserve string content unchanged;
• concatenate top-level type: "text" chunks in order;
• recognize but not expose thinking chunks in the 4.5.1 provider;
• ignore reference, unknown, null, empty, and malformed chunks safely; and
• leave outgoing requests, tool calls, and audio handling unchanged.

This fixed the observed failure. After deployment:

• an explicit web-search request completed two parallel MCP searches and returned an answer; and
• retrying an existing conversation that had previously failed with this parser error returned an answer.

The patch below is the exact tested 4.5.1 workaround. It is not necessarily the preferred implementation for current main, because current main also has a streaming parser and structured reasoning support.

Tested integration_openai 4.5.1 workaround diff

--- a/lib/Service/OpenAiAPIService.php
+++ b/lib/Service/OpenAiAPIService.php
@@ -708,8 +708,9 @@
 			}
 
 			// always try to get a message
-			if (isset($choice['message']['content']) && is_string($choice['message']['content'])) {
-				$completions['messages'][] = $choice['message']['content'];
+			$content = $this->normalizeChatMessageContent($choice['message']['content'] ?? null);
+			if ($content !== null) {
+				$completions['messages'][] = $content;
 			}
 			if (isset($choice['message']['audio'], $choice['message']['audio']['data']) && is_string($choice['message']['audio']['data'])) {
 				$completions['audio_messages'][] = $choice['message'];
@@ -720,6 +721,36 @@
 	}
 
 	/**
+	 * Normalize OpenAI-compatible string content and typed content chunks.
+	 *
+	 * Thinking chunks are recognized but intentionally not exposed by this
+	 * provider version. Unknown and malformed chunks are ignored.
+	 */
+	private function normalizeChatMessageContent(mixed $content): ?string {
+		if (is_string($content)) {
+			return $content;
+		}
+		if (!is_array($content) || !array_is_list($content)) {
+			return null;
+		}
+
+		$textChunks = [];
+		foreach ($content as $chunk) {
+			if (!is_array($chunk)) {
+				continue;
+			}
+			if (($chunk['type'] ?? null) === 'thinking') {
+				continue;
+			}
+			if (($chunk['type'] ?? null) === 'text' && isset($chunk['text']) && is_string($chunk['text'])) {
+				$textChunks[] = $chunk['text'];
+			}
+		}
+
+		return $textChunks === [] ? null : implode('', $textChunks);
+	}
+
+	/**
 	 * @param string $configKey
 	 * @return array|null
 	 */

Local regression fixtures covered:

• existing OpenAI string content;
• Mistral thinking plus text chunks;
• interleaved text and reference chunks;
• multiple text and unknown chunks;
• null, empty, and malformed content; and
• unchanged existing tool-call and audio normalization.

The patched file passed PHP 8.3 lint.

Current upstream main also has streaming response parsing. A complete upstream fix may therefore need the same typed-content support in both non-streaming normalization and streaming SSE parsing.

Investigation assistance

I encountered this bug multiple times. OpenAI gpt-5.6-sol was used to help compare the synthetic occurrences, construct a privacy-safe replay, inspect the relevant schemas, and prepare the local workaround and tests.

I supplied the provider credential locally through getpass, approved and performed the production deployment, and manually validated the resulting Assistant and MCP behavior.

Expected Behavior

OpenAI-compatible assistant responses should produce a final text result when message.content is either:

• a normal string; or
• a list containing valid type: "text" chunks.

For typed content, the text chunks should be concatenated in order. Thinking, reference, unknown, or malformed chunks should not cause otherwise valid final text to be discarded.

Existing behavior for string content, separate reasoning_content, tool calls, audio, and ordinary OpenAI-compatible providers should remain unchanged.

To Reproduce

Intermittent provider reproduction

1. Configure integration_openai 4.5.1 with the Mistral EU OpenAI-compatible endpoint and mistral-small-2603.

2. Submit a sufficiently involved chat request, optionally with tools.

3. Allow the provider to complete the request successfully.

4. Repeat if necessary because Mistral may return either string or typed content for the same request.

5. When message.content is an array of typed chunks, observe that integration_openai returns no message and the task can fail with:

   No result in OpenAI/LocalAI response.
   

Provider-level typed-content reproduction

A near-deterministic way to request the relevant response shape is to send a separate diagnostic request with reasoning_effort: "high":

{
  "model": "mistral-small-2603",
  "messages": [
    {
      "role": "user",
      "content": "Tell me more about Amsterdam:\n1. What is its history?\n2. What are its demographics?\n3. Is it worth visiting for sightseeing?"
    }
  ],
  "n": 1,
  "max_tokens": 5000,
  "reasoning_effort": "high"
}

In my test, the equivalent synthetic request returned HTTP 200 with:

message.content type: array
chunk types: thinking, text
finish_reason: stop

Version 4.5.1 extracted no message from that response. The parameter is only intended to make the typed response shape reproducible; it is not proposed as a production setting or workaround.

Deterministic parser-level reproduction

Pass a successful synthetic chat-completion response shaped like this through the 4.5.1 response normalizer:

{
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": [
          {
            "type": "thinking",
            "thinking": [
              {
                "type": "text",
                "text": "Synthetic reasoning"
              }
            ]
          },
          {
            "type": "text",
            "text": "Synthetic final answer"
          }
        ]
      },
      "finish_reason": "stop"
    }
  ]
}

Expected result:

Synthetic final answer

Actual 4.5.1 result:

No message is extracted.

[dtump]

I hope it's okay that I asked AI to help me investigate and file this issue. I tried it myself at first, but it was quite tedious/hard to do. If this is unacceptable, then please just ignore the issue I created with AI and close it.

I also didn't want to open one of those typical vibe coder PR's with a fix for Mistral that I didn't test against OpenAI or an OpenAI-compatible endpoint.

[lukasdotcom]

I hope it's okay that I asked AI to help me investigate and file this issue. I tried it myself at first, but it was quite tedious/hard to do. If this is unacceptable, then please just ignore the issue I created with AI and close it.

I also didn't want to open one of those typical vibe coder PR's with a fix for Mistral that I didn't test against OpenAI or an OpenAI-compatible endpoint.

Hi @dtump,

I tried recreating this issue and can't seem to recreate it in mistral. Do you have a specific model and prompt that I could use to recreate it on my end. Preferably one that doesn't use context agent tool calls.

About the AI policy the part that matters for this issue is the requirement that communication must be human written. You are free to debug and investigate an issue with AI. For exact details you can read the policy here: https://github.com/nextcloud/.github/blob/master/AI_POLICY.md

[dtump]

Hi @dtump,

I tried recreating this issue and can't seem to recreate it in mistral. Do you have a specific model and prompt that I could use to recreate it on my end. Preferably one that doesn't use context agent tool calls.

About the AI policy the part that matters for this issue is the requirement that communication must be human written. You are free to debug and investigate an issue with AI. For exact details you can read the policy here: https://github.com/nextcloud/.github/blob/master/AI_POLICY.md

I was using mistral-small-2603. Basically more complex prompts triggered the issue, also logging a RuntimeException: No result in OpenAI/LocalAI response in the nextcloud log. It was easy to trigger it with multiple questions in a single prompt, so my test prompt that consistently triggered it was:

Tell me more about Amsterdam:
1. What is its history?
2. What are its demographics?
3. Is it worth visiting for sightseeing?

I was only able to trigger it when it also did a tool call, in these test cases using a Brave MCP Server for web searches. I'm not sure if it can be triggered without tool calls.

It took me a few hours today to debug it, even with help from AI. It was a bit too much text to write myself, so I used AI to draft the issue text as well (as all the context was in the session as well). I understand this is quite annoying, because it's not that enjoyable to read a tonne of AI text.

[lukasdotcom]

Hi @dtump,

Thanks turns out you do need context agent with tool calls to recreate it otherwise mistral doesn't use references, but I can now recreate it. I'll be creating a pr (#409) with a fix and backporting it so you don't need to wait until Nextcloud 35 releases. Also the way AI formatted your issue didn't bother me that much as the first few paragraph was enough context for me to get the problem. I would recommend in the future to keep a concise summary of the issue and how to recreate it and you can hide the other stuff in a details page.

Patch if you want to test it yourself

diff --git a/lib/Service/OpenAiAPIService.php b/lib/Service/OpenAiAPIService.php
index 7519d26..3af708a 100644
--- a/lib/Service/OpenAiAPIService.php
+++ b/lib/Service/OpenAiAPIService.php
@@ -708,8 +708,19 @@ class OpenAiAPIService {
 			}
 
 			// always try to get a message
-			if (isset($choice['message']['content']) && is_string($choice['message']['content'])) {
-				$completions['messages'][] = $choice['message']['content'];
+			if (isset($choice['message']['content'])) {
+				if (is_string($choice['message']['content'])) {
+					$completions['messages'][] = $choice['message']['content'];
+				} else if (is_array($choice['message']['content'])) {
+					$messageContent = [];
+					// Handle Mistral references
+					foreach ($choice['message']['content'] as $content) {
+						if ($content['type'] === 'text' && is_string($content['text'])) {
+							$messageContent[] = $content['text'];
+						}
+					}
+					$completions['messages'][] = implode(' ', $messageContent);
+				}
 			}
 			if (isset($choice['message']['audio'], $choice['message']['audio']['data']) && is_string($choice['message']['audio']['data'])) {
 				$completions['audio_messages'][] = $choice['message'];

[dtump]

Hey @lukasdotcom,

Thanks for the quick response! Your patch looks very similar to the workaround/fix I generated with AI and put in the issue, so I'm confident that this will indeed resolve it. I'll try to be more concise next time, but in my mind every detail is important and I'm sometimes somewhat chaotic in my texts, hence the help from AI to draft the issue text.

Anyway, the fix is much appreciated, I really like that we can use Mistral in Nextcloud Assistant.

Enjoy your day!