[Bug] Volcengine Ark tool-call assistant content needs live endpoint validation

Area

Provider adapter / Volcengine Ark compatibility

Current status

The original report reproduced a Volcengine Ark 400 MissingParameter error when conversation history contained an assistant message with tool_calls and empty text content.

The original failing error was:

Provider error 400:
{"error":{"code":"MissingParameter","message":"The request failed because it is missing `input.content.text` parameter.","param":"input.content.text","type":"BadRequest"}}

A provider-specific compatibility change has since landed on dev.

Current OpenCodex detects Ark hostnames and uses an Ark-specific structured placeholder for assistant history entries that contain tool calls or reasoning but no textual content.

The relevant implementation is in:

src/adapters/openai-chat.ts

and originated in commit:

2eebd9268

The corresponding regression coverage is in:

tests/volcengine-ark-assistant-content.test.ts

However, the emitted content shape was inferred from Ark's error contract and has not yet been confirmed against a live Volcengine Ark endpoint.

This issue therefore remains open for live compatibility validation.

Original reproduction

The original report used OpenCodex:

2.7.43-preview.20260728

with a conversation containing an assistant tool-call message with no textual content.

Conceptually:

{
  "role": "assistant",
  "content": "",
  "tool_calls": [
    {
      "id": "call_1",
      "type": "function",
      "function": {
        "name": "shell",
        "arguments": "{\"cmd\":\"ls\"}"
      }
    }
  ]
}

The Ark endpoint returned:

400 MissingParameter: input.content.text

Single-turn requests without tool-call history worked.

What current OpenCodex does

The previous generic serialization used an empty string for assistant messages containing tool calls but no text.

Current dev treats Ark separately.

For recognized Ark hosts, OpenCodex emits a structured empty-text placeholder instead of the generic empty-string representation.

Conceptually:

{
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": ""
    }
  ],
  "tool_calls": [...]
}

This behavior is intentionally provider-specific.

Other providers retain their existing serialization because their validation requirements differ.

Why the original suggested fix is no longer current

The original report suggested replacing the empty string with a single space:

""

→

" "

That should no longer be treated as the proposed fix.

There is insufficient evidence that Ark consistently accepts whitespace-only text, and changing the representation globally could break providers with different assistant-content requirements.

The current implementation instead isolates Ark behavior behind provider/host detection.

What we need to validate

Someone with access to a live Volcengine Ark account should repeat the original multi-turn tool-call reproduction against:

current dev; or
the latest release containing commit 2eebd9268.

Please report:

Whether the original 400 MissingParameter input.content.text still occurs.
The exact regional Ark hostname used.
If it still fails, the redacted serialized assistant message sent upstream.
The exact Ark error response.

Keys, prompts, tool arguments, and private content can be removed.

The important information is the shape of the assistant content field.

Hostname validation

Please include the exact endpoint hostname used for the reproduction.

Current Ark detection includes known regional Ark hosts such as:

ark.cn-beijing.volces.com
ark.ap-southeast.volces.com

If another Ark hostname is affected, the compatibility gate may need to be expanded.

Expected result

A conversation containing an assistant message with tool_calls but no natural-language assistant text should be accepted by Ark and continue normally instead of returning:

400 MissingParameter input.content.text

Acceptance / closure criteria

Close as fixed

Close this issue if a live Ark test on current OpenCodex confirms that the original reproduction now succeeds.

When closing, reference:

2eebd9268

as the compatibility change that resolved it.

Keep open and update

If the current implementation still produces the Ark 400:

provide the regional hostname;
capture the serialized assistant content shape;
capture the exact error response;
update the Ark-specific serializer based on the observed live contract;
add a regression test for the confirmed shape.

Checks

Original failure is documented.
A provider-specific candidate fix is present on current dev.
The original single-space suggestion is no longer treated as the implementation plan.
Local regression coverage exists.
Current behavior confirmed against a live Volcengine Ark endpoint.

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

fix(providers): give Volcengine Ark non-empty assistant text on tool …

A fix is staged on codex/260731-pr-merge-round (2eebd9268), but it needs your confirmation before it can be called done — I have no Ark credentials, so nothing here has touched a live endpoint.

What the code does now. For Ark hostnames only, an assistant history entry that carries just tool calls (or just reasoning) is serialized with content: [{"type":"text","text":""}] instead of content: "". Every other provider keeps "".

Why not simply drop content, or send a space. Both were considered and rejected:

"" cannot be changed globally. xAI's validator rejects the opposite way — "Each message must have at least one content element" — so the two provider contracts are in direct conflict. That is why the fix is host-gated rather than a general change.
A single space was my first attempt. There is no evidence Ark accepts it, and a validator that trims whitespace would reject it exactly as it rejects "". It would have passed every local test and still 400'd against your endpoint.

The reasoning behind the array, and its limit. Your error names input.content.text — a nested path. No bare string exposes a content.text field at all, which points at the structured content form. But Ark's published examples only show array content for multimodal user input; nothing in the reference covers an assistant history entry. So this is inferred from the error message, not confirmed. The code and tests both say so rather than implying certainty.

What would settle it. If you can re-run your exact reproduction against the branch, two things are worth knowing: whether the array form is accepted, and whether omitting content entirely also works (which would be cleaner if Ark allows it). Also useful: which Ark regional hostname you use. The gate currently covers ark.cn-beijing.volces.com and ark.ap-southeast.volces.com.

Staying open until that lands. The branch merges into dev and ships once the optimization work in flight there completes.

docs(plan): record the round outcome, including what was wrong

Triage status: a host-gated candidate fix exists (2eebd92), but we cannot merge it blind. Could you confirm against your live Ark account: (1) does the candidate build resolve the 400 on assistant messages with tool_calls, and (2) which regional Ark hostname is your failing endpoint served from? With those two confirmations we can move to a PR.

Triage: the branch now emits Ark-specific structured empty assistant content (src/adapters/openai-chat.ts:384, tests/volcengine-ark-assistant-content.test.ts), but that path is explicitly marked unverified against a live Ark endpoint. Leaving open until someone with an Ark key confirms the 400 is gone — if you can reproduce on the latest dev, a redacted request/response pair would close this fast.

Triaged against current dev. The fix you need may already be in, but I am not closing this on an inference, and the reason is worth stating.

src/adapters/openai-chat.ts:491-515 detects the Ark host and emits a structured placeholder for an assistant message carrying only tool calls, and all three placeholder sites call it (:315, :318, :347). Commit 2eebd9268 is an ancestor of dev, so that code is shipping.

But its own test says the shape was never validated against a live endpoint — tests/volcengine-ark-assistant-content.test.ts:16-18 records that the structured empty array is inferred from the error message, not confirmed by Ark. So "we probably fixed it" is the honest status, and closing on that would just move the failure to whoever hits it next.

Three things would settle it, from your setup:

The result on current dev (or the latest release) for the same conversation that produced the 400 — does it still fail?
Your regional Ark hostname. ark.cn-beijing.volces.com and the other regional endpoints do not always behave identically, and the host detection is a string match.
If it still fails: the redacted request body for the assistant message with tool_calls, plus the exact error payload. Redact the key and any content; the content field's shape is the whole question.

If it now works, say so and I will close with the commit named.

Since this has been stale from your side for two weeks, I will be closing this. If you still encounter this, feel free to open a new issue! Thank you.

fix(providers): give Volcengine Ark non-empty assistant text on tool …

docs(plan): record the round outcome, including what was wrong

Navigation Menu

Repository navigation

[Bug] Volcengine Ark tool-call assistant content needs live endpoint validation #796

Area

Current status

Original reproduction

What current OpenCodex does

Why the original suggested fix is no longer current

What we need to validate

Hostname validation

Expected result

Acceptance / closure criteria

Close as fixed

Keep open and update

Checks

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[Bug] Volcengine Ark tool-call assistant content needs live endpoint validation #796

Description

Area

Current status

Original reproduction

What current OpenCodex does

Why the original suggested fix is no longer current

What we need to validate

Hostname validation

Expected result

Acceptance / closure criteria

Close as fixed

Keep open and update

Checks

Activity

github-actions commented on Jul 31, 2026

lidge-jun commented on Jul 31, 2026

lidge-jun commented on Aug 2, 2026

lidge-jun commented on Aug 2, 2026

lidge-jun commented on Aug 3, 2026

Wibias commented on Aug 11, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions