[Bug] `openaicompatible` provider drops `content` from response when `reasoning_details[*].format` is `MiniMax-response-v1` (empty bot post, no error)

[jsmarble]

Summary

When a bot's model is set to a model that returns reasoning_details with format: "MiniMax-response-v1" (e.g. Cloudflare AI Gateway's minimax/m3), the plugin's bifrost client creates a custom_llmbot post with an empty message. The user sees no reply. No error is logged. The conversation has only the user turn in llm_turns — no assistant turn is recorded.

This is distinct from the dynamic/default issue #869 — that one is a missing model field in the request; this one is a content field being dropped from the response.

Affected

• Plugin: mattermost-plugin-agents v2.4.2
• Provider type: openaicompatible (configured against Cloudflare AI Gateway)
• Model value that triggers it: any model whose response carries reasoning_details[*].format: "MiniMax-response-v1" (e.g. minimax/m3)

Prerequisites

Have a Cloudflare AI Gateway configured with a dynamic route called dynamic/default that routes to one or more AI models.

Reproduction

1. Install mattermost-plugin-agents v2.4.2.
2. Configure an openaicompatible service against Cloudflare AI Gateway.
3. Set a bot's model to minimax/m3.
4. Ping the bot in a DM.
5. Observe: the bot creates an empty custom_llmbot post. The user sees nothing. No assistant turn appears in llm_turns.

Expected

The full content from the upstream response is rendered in the bot's reply.

Actual

• custom_llmbot post is created with empty message.
• No error in journalctl.
• No assistant turn in llm_turns for the conversation.

Evidence — direct test against the gateway works fine

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/ai/v1/chat/completions' \
  -H 'Authorization: Bearer <CF_TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{"model":"minimax/m3","messages":[{"role":"user","content":"hi"}],"max_tokens":50,"stream":false}'
# HTTP 200
# Response includes:
#   content: "Hi there! 👋 How are you doing today? Is there something I can help you with?"
#   reasoning_content: "The user is just saying \"hi\"..."
#   reasoning_details: [{type: "reasoning.text", format: "MiniMax-response-v1", ...}]
#   finish_reason: "stop"

Why other @cf/... models work

Comparing response shapes from the same gateway:

@cf/openai/gpt-oss-120b (works fine):

{
  "choices": [{
    "message": {
      "content": "",
      "reasoning_content": "...",
      "annotations": ..., "audio": ..., "function_call": ..., "refusal": ..., "role": ..., "tool_calls": ...
    }
  }]
}

Note: reasoning_details: None.

minimax/m3 (broken — empty bot reply):

{
  "choices": [{
    "message": {
      "content": "Hi there! 👋 How are you doing today? ...",
      "reasoning_content": "...",
      "reasoning_details": [
        {"type": "reasoning.text", "id": "reasoning-text-1", "format": "MiniMax-response-v1", "index": 0, "text": "..."}
      ],
      "role": "assistant"
    }
  }]
}

The presence of reasoning_details with format: "MiniMax-response-v1" correlates with the bifrost streaming combiner dropping the content field from the post.

Workaround

Use @cf/openai/gpt-oss-120b (or any model whose reasoning_details is None or absent) until this is fixed. We currently have an agent on gpt-oss-120b and it responds correctly.

Environment

• Mattermost 11.9.0 (Ubuntu 24.04, kernel 6.8.0)
• mattermost-plugin-agents v2.4.2

[mattezell]

Second reproduction shape, confirming this is not MiniMax-specific but a general thinking-model interaction: an openaicompatible service pointed at a llama.cpp server (llama-swap) running Qwen3.6-27B -- a thinking model whose <think> output llama.cpp splits into reasoning_content in the chat-completions stream. Result: the model streams a full response (8.7 KB of SSE observed server-side, HTTP 200), the bot post is empty, no error anywhere. Disabling the bot's reasoning setting does not help (the model thinks by default; the server still emits reasoning_content).

Same pipeline with a non-thinking model (Devstral-24B) works perfectly, including MCP tool calls -- isolating the drop to the reasoning-details handling this issue describes. Since llama.cpp is a very common self-hosted backend and Qwen-family thinking models are ubiquitous on it, the blast radius is bigger than the MiniMax title suggests. Plugin v2.4.2, server 11.9.0.