Skip to content

[Bug] 400 "A parameter specified is not valid" with volcengine kimi-k2.7-code on tool-call continuation (regression from 2.7.42) #1570

Description

@CarverZheng

Environment

  • opencodex 2.12.0 (confirmed still present in 2.13.0)
  • Provider: volcengine (https://ark.cn-beijing.volces.com/api/coding/v3), model kimi-k2.7-code
  • Adapter: openai-chat

Problem

Requests carrying assistant tool_calls + tool messages get rejected by the upstream:

Provider error 400: A parameter specified in the request is not valid

Plain conversations work; only tool-call continuation turns fail. This is intermittent from the client's perspective because only requests with tool history trigger it.

Root cause

emptyAssistantContent() in src/adapters/openai-chat.ts (introduced in 2.12.0) returns an empty text ARRAY for Volcengine Ark providers:

function emptyAssistantContent(provider) {
  return isVolcengineArkTarget(provider) ? [{ type: "text", text: "" }] : "";
}

When an assistant message has tool_calls but no text, this becomes content: [{type:"text",text:""}]. Volcengine kimi-k2.7-code rejects that shape (strict validator); DeepSeek tolerates it, so only kimi is affected.

2.7.42 used an empty string on the same path, which every Ark model accepts:

if (!chatMsg.content) chatMsg.content = "";

Reproduction (direct API call)

POST /api/coding/v3/chat/completions, model kimi-k2.7-code:

assistant message result
content=null + tool_calls 200
content="" + tool_calls 200
content=[{"type":"text","text":""}] + tool_calls 400 "A parameter specified is not valid"

Impact

Any session routed to Volcengine kimi-k2.7-code in a tool-calling loop gets 400s. Verified that all other Ark models tested (deepseek-v4-flash, deepseek-v4-pro, doubao-seed-2.1-turbo, glm-5.2, minimax-m3, kimi-k2.6) accept content="".

Suggested fix

Do not emit an empty text array from emptyAssistantContent(). Return "" (as 2.7.42) for all providers, or special-case Ark kimi models.

Workaround (local patch)

Changing emptyAssistantContent to return "" fixes it; verified all 7 tested Ark models return 200.

Note

The noStructuredOutputModels option introduced in 2.13.0 addresses a separate response_format passthrough issue and does not affect this bug.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    toolstool_calls, MCP, web-search / sidecar tools

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions