Skip to content

[Bug]: detectCompat in openai-completions.ts misses Xiaomi endpoints for requiresReasoningContentOnAssistantMessages — diverges from openai-completions-compat.ts #91106

@KrasimirKralev

Description

@KrasimirKralev

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

openai-completions-compat.ts and openai-completions.ts disagree about which endpoints need requiresReasoningContentOnAssistantMessages. The agent-layer compat covers both DeepSeek and Xiaomi AI Studio endpoints; the provider-layer auto-detect (detectCompat) only covers DeepSeek. Xiaomi multi-turn sessions that go through the provider layer without the agent transport will not inject the required empty reasoning_content field on replayed assistant messages, causing the provider API to reject the request.

Steps to reproduce

  1. Configure an OpenClaw model using api: "openai-completions" pointed at a Xiaomi AI Studio (MiModel) endpoint:
    models:
      providers:
        - type: openai-completions
          apiUrl: "https://api.ai.xiaomi.com/v1"
          models:
            - id: "MiMo-7B-RL"
  2. Start a multi-turn conversation session that triggers assistant-message replay (second+ turn of a reasoning session).
  3. Observe: Xiaomi API returns a validation error because replayed assistant messages lack the required reasoning_content field.

Rolling back to route the same endpoint through openai-transport-stream.ts (i.e., through an agent with useTransportStream: true) bypasses the bug because the agent layer's openai-completions-compat.ts correctly sets requiresReasoningContentOnAssistantMessages: true for endpointClass === "xiaomi-native".

Expected behavior

detectCompat in openai-completions.ts should return requiresReasoningContentOnAssistantMessages: true for Xiaomi-native endpoints, consistent with the agent-transport layer.

Actual behavior

detectCompat in openai-completions.ts only returns requiresReasoningContentOnAssistantMessages: isDeepSeek. Xiaomi endpoints are not covered.


Code pointers (analysis, not observed)

Divergence found at:

  • src/agents/openai-completions-compat.ts — agent-layer compat auto-detect:

    requiresReasoningContentOnAssistantMessages: isDeepSeek || isXiaomi,

    where isXiaomi = endpointClass === "xiaomi-native" || endpointClass === "xai-native".

  • src/llm/providers/openai-completions.ts — provider-layer detectCompat:

    requiresReasoningContentOnAssistantMessages: isDeepSeek,

    isXiaomi is absent.

The two files serve different call paths. openai-completions-compat.ts feeds the transport-stream layer (src/agents/openai-transport-stream.ts) which our PR #89832 now correctly wires through getCompat. openai-completions.ts's detectCompat is used when the provider is called without the higher-level transport (e.g., tool-result or completion-only code paths). For Xiaomi endpoints in that lower path, the field remains false and assistant-message replay omits reasoning_content.

The divergence was likely introduced when isXiaomi was added to openai-completions-compat.ts without a corresponding update to detectCompat in openai-completions.ts.

This pattern mirrors the original requiresReasoningContentOnAssistantMessages schema gap fixed in PR #89832 (issue #89660), but at the auto-detection layer rather than the configuration layer.

Proposed fix options

Option A (preferred): Add isXiaomi to openai-completions.ts detectCompat, matching the agent-compat logic:

// src/llm/providers/openai-completions.ts — detectCompat
requiresReasoningContentOnAssistantMessages: isDeepSeek || isXiaomi,  // add isXiaomi

Requires importing or replicating the endpointClass === "xiaomi-native" || "xai-native" check already present in openai-completions-compat.ts.

Option B: Extract a shared requiresReasoningContent(model) utility used by both files, so the set of affected endpoints stays in one place and can't diverge again.

Option C: Document that detectCompat in openai-completions.ts intentionally omits Xiaomi (if these endpoints always go through the transport-stream path). Add a test assertion confirming Xiaomi endpoints are never reached through the provider path without the transport-stream intermediary.


Analysis derived from static code search; live reproduction with a Xiaomi AI Studio API key was not performed. Root cause confidence: high (direct code comparison); user impact scope: limited to Xiaomi AI Studio endpoints using the openai-completions provider type without the agent transport layer.

This issue was investigated by an automated contributor (openclaw-cron). Analysis follows the #89832 fix; the reviewer who merged that PR may have context on the intended call-path separation between openai-completions-compat.ts and openai-completions.ts. If the gap is by design, please close with a brief note — it would clarify the architecture for future contributors.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:auth-providerAuth, provider routing, model choice, or SecretRef resolution may break.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions