[Provider compatibility] Command Code returns 502 upstream_server_error: "Tool result is missing for tool call"

[Wibias]

Client or integration

Codex App

Provider or upstream service

Command Code (api.commandcode.ai), OAuth account login (ocx login command-code)

OpenCodex version

2.11.1 (proxy on dev, commit ba1df18a; the failure occurred on 2026-08-10)

Endpoint or capability

/alpha/generate (Command Code proprietary streaming endpoint); tool-call continuation over the Responses inbound protocol; tool results / tool-result pairing

Current behaviour

A Codex App conversation routed explicitly to command-code/deepseek/deepseek-v4-flash at high reasoning effort failed with a 502:

502 Bad upstream response

The upstream provider returned an invalid or failed response through the proxy.

Error: upstream_server_error
Upstream reason: Provider stream error: Tool result is missing for tool call call_01_ET_JkpgP70Q1U7ta7UYci6z5139.

Request metadata (sanitized):

• request ID: ocx-msmdjykf-3l
• inbound protocol: responses
• requested model: command-code/deepseek-deepseek-v4-flash
• resolved model: deepseek/deepseek-v4-flash
• reasoning effort: high (reasoning_effort=high)
• status: 502
• error code: upstream_server_error
• close reason: terminal; transport phase: terminal_sse; terminal source: upstream
• duration: 320 ms (failed quickly, before any output tokens)
• usage: not reported
• route: explicit-provider (command-code), single candidate, no recovery

Expected behaviour

The proxy should either surface a clearer provider-side error for a tool-result mismatch, or ensure every tool call the upstream requested has its corresponding result forwarded so the continuation succeeds. The request should not fail with a generic 502 that gives the client no way to recover the turn. If the upstream is at fault (it emitted an error event for a tool result that ocx did send), the error should be classified and retried or surfaced distinctly rather than treated as a plain stream failure.

Minimal redacted request or reproduction

Not directly reproducible from a single log; the failure occurs on a tool-heavy turn. The relevant sequence:

1. ocx start (proxy on dev).
2. In Codex App, select model command-code/deepseek-deepseek-v4-flash.
3. Run a turn that causes the model to issue multiple tool calls (e.g. shell/file tools) and then continues after the tool results.
4. Observe a 502 with the upstream error Tool result is missing for tool call call_01_... on the continuation.

The local adapter maps tool results to { role: "tool", content: [{ type: "tool-result", toolCallId, toolName, output }] } per src/adapters/command-code.ts (wireMessages). The upstream rejected a specific call id as having no result, which points at either the continuation not carrying that call's result or the upstream not accepting the pairing.

Actual response or error

{
  "requestId": "ocx-msmdjykf-3l",
  "model": "deepseek/deepseek-v4-flash",
  "provider": "command-code",
  "inboundProtocol": "responses",
  "requestedModel": "command-code/deepseek-deepseek-v4-flash",
  "requestedEffort": "high",
  "effectiveEffort": "high",
  "status": 502,
  "durationMs": 320,
  "errorCode": "upstream_server_error",
  "closeReason": "terminal",
  "upstreamError": "Provider stream error: Tool result is missing for tool call call_01_ET_JkpgP70Q1U7ta7UYci6z5139.",
  "usageStatus": "unreported",
  "transportPhase": "terminal_sse",
  "terminalSource": "upstream"
}

Upstream documentation

https://commandcode.ai/docs/provider (Command Code Provider API; the /alpha/generate endpoint is used by the adapter; see also the adapter at src/adapters/command-code.ts)

Suggested mapping or implementation notes

1. Confirm whether the tool-result continuation is missing a result for one emitted tool call, or whether the upstream rejects the pairing for another reason (e.g. a tool call that never produced a tool_result in the conversation history).
2. If a tool call is missing its result, decide whether the proxy should synthesize an explicit missing-result error or skip the stale call rather than fail the whole turn with 502.
3. Consider classifying this upstream error event distinctly from a generic stream failure so the dashboard/log distinguishes provider-side tool-result validation from network/stream stalls.
4. This is not the same as [Provider compatibility] DeepSeek V4 Flash Responses 502 needs v2.11+ reproduction #1176 (DeepSeek built-in bounded-JSON stall) or #875/#946 (Responses tool-call continuation stall); those are DeepSeek native adapter issues. This is the Command Code adapter surfacing an upstream tool-result validation error.

Additional context and attachments

Related issues: #1176 (DeepSeek V4 Flash Responses 502, built-in deepseek provider, bounded-JSON stall — different failure), #875 / #946 (DeepSeek Responses tool-call stall — different provider adapter), #620 (Anthropic tool_use without tool_result — similar upstream-side validation concept, different provider).

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on an upstream specification or a concrete client requirement.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}

[Wibias]

[GD] Opened PR #1411 to address this.

[lidge-jun]

Fixed by #1411 and released in v2.12.0, now on npm as @bitkyc08/opencodex@2.12.0.

Two commits were needed. aca275265 pairs every declared tool call with its result and synthesizes an explicit missing-result error rather than sending a request that violates the upstream invariant; fc1c729ec then buffers image carriers until the tool results close, which was a separate way the same 502 could surface when a tool returned an image.

A residual upstream validation failure is now reported as missing_tool_result instead of an undifferentiated stream error, so if anything similar recurs the cause is visible in the error itself.

Verified in the released tree: git merge-base --is-ancestor aca275265 9c051342d and the same check for fc1c729ec both exit 0, and git tag --contains fc1c729ec includes v2.12.0.

Thanks for the sanitized failure signature — it made the wire invariant easy to pin down. Please reopen if 2.12.0 still reproduces it.