fix(provider): inject placeholder text for empty assistant wire messages on openai-compatible by codeg-dev · Pull Request #38270 · anomalyco/opencode

codeg-dev · 2026-07-22T08:33:23Z

Issue for this PR

Related: #37651 / #37624 (empty reasoning parts — complementary; that fix skips empty reasoning parts, while this PR covers assistant wire messages that still end up with no non-empty text at all, e.g. aborted reasoning-only turns and step-start split pieces). Also related: #31046 (empty text parts), #28507, #37852, #37372.

Type of change

Bug fix

What does this PR do?

@ai-sdk/openai-compatible serializes assistant messages without any non-empty text as content: "" or null. Strict providers (Kimi/Moonshot via chat/completions) reject the whole request with 400 "the message at position N with role 'assistant' must not be empty". Once a session contains such a turn it is permanently bricked: every retry fails the same way and appends another empty artifact message.

Shapes that produce an empty assistant wire message:

an aborted turn persisted with only step-start / reasoning / patch parts (Aborted assistant turn persisted with zero content bricks the session: empty assistant message replayed to provider (400 "must not be empty") #37946)
a tool-call-only turn (no text part)
the per-step pieces after convertToModelMessages splits a multi-step turn at step-start (a guard applied only at the UIMessage stage covers the first piece but not the later ones)
an assistant message whose only text part is empty

This PR runs a post-pass over the final ModelMessage list in toModelMessagesEffect: when the target model uses @ai-sdk/openai-compatible, any assistant message lacking non-empty text gets a single-space text part unshifted, so every split piece is covered individually.

Why inject instead of dropping the empty message: dropping an assistant turn that carries tool calls would break tool-call/tool-result pairing, and dropping a reasoning-only turn would discard interleaved reasoning_content that providers like Kimi use as history context. A single-space placeholder keeps history semantics intact while satisfying the non-empty-content requirement.

Scoped to openai-compatible on purpose: OpenAI and Anthropic accept textless tool-call turns, and Anthropic signed thinking is handled before conversion.

How did you verify your code works?

7 new regression tests in test/session/message-v2.test.ts (tool-call-only, step-start split pieces, empty-text-only, reasoning-only passthrough, anthropic unaffected, step-start-only still dropped, existing text untouched): 43/43 pass.
tsgo --noEmit clean.
Replayed a bricked Kimi K3 session containing an aborted reasoning-only turn through a patched build: the follow-up request succeeded (previously 400 at the artifact position, and the position no longer advances on retry).

Screenshots / recordings

Not applicable.

Checklist

I have tested my changes locally
I have not included unrelated changes in this PR

Prepared with AI assistance (OpenCode agent); reviewed and verified by the author before submission.

…ges on openai-compatible @ai-sdk/openai-compatible serializes assistant messages without any non-empty text as content: "" or null — tool-call-only turns, the per-step pieces produced by step-start splitting, and aborted reasoning-only turns all hit this. Strict providers (Kimi/Moonshot via chat/completions) reject the whole request with 400 "the message at position N with role 'assistant' must not be empty", permanently bricking the session as each failed retry appends another empty artifact message. Run a post-pass over the final ModelMessage list in toModelMessagesEffect when the target model uses @ai-sdk/openai-compatible and unshift a single-space text part into any assistant message lacking non-empty text, so every split piece is covered individually. Scoped to openai-compatible: OpenAI and Anthropic accept textless tool-call turns, and Anthropic signed thinking is handled before conversion. Fixes anomalyco#37946 Tests: 43/43 in test/session/message-v2.test.ts (7 new: tool-call-only, step-start split pieces, empty-text-only, reasoning-only passthrough, anthropic unaffected, step-start-only still dropped, existing text untouched)

github-actions · 2026-07-22T08:34:25Z

The following comment was made by an LLM, it may be inaccurate:

I found a related PR that's worth reviewing:

PR #33899 - fix(provider): ensure non-empty assistant content for openai-compatible (#33280)
#33899

This PR appears to address a similar issue of ensuring non-empty assistant content for the openai-compatible provider. It may have already tackled part of this problem or provide relevant context for the current PR.

The other results are either the current PR itself (#38270) or tangentially related PRs about empty content, reasoning parts, and provider fixes.

You should verify whether PR #33899 already solves the issue or if this PR (#38270) is extending/improving upon that previous fix.

codeg-dev · 2026-07-22T08:59:50Z

Verified the overlap with #33899 — thanks for surfacing it. Short version: #33899 does not fix #37946; this PR covers a superset of #33899's cases.

#33899 (still open, unmerged) patches ProviderTransform.message in src/provider/transform.ts and injects the single-space text only when the assistant message has tool calls but no text — its guard is if (hasText || !hasToolCall) return msg. Assistant messages with no tool calls and no text pass through untouched.

#37946's failing shape is exactly that untouched case: an aborted turn persisted with only step-start / reasoning / patch parts — no text, no tool calls — replays as content: [] (or ""), and strict providers reject the whole request with 400. #33899's !hasToolCall early-return leaves it empty. (The two issues are also different failure modes: #33280 is a lenient proxy injecting a visible placeholder into the transcript; #37946 is a strict provider rejecting the request and bricking the session.)

Coverage comparison:

wire message shape	#33899	this PR
tool-call-only, no text (#33280)	✅	✅
step-start split pieces (tool-call-only after split)	✅	✅
aborted reasoning-only turn, no text + no tool calls (#37946)	❌ (`!hasToolCall` skip)	✅
assistant message whose only text part is `""`	❌	✅
string `content: ""`	❌ (skipped)	✅ (→ `" "`)

Layer note: this PR runs the guard in toModelMessagesEffect, which produces the list later passed to ProviderTransform.message in the request path; #33899 runs inside ProviderTransform.message. If both were merged they would not double-inject (both check for existing non-empty text first), but one guard at one layer would be cleaner. Happy to move this guard into ProviderTransform.message with the hasToolCall requirement dropped — i.e. #33899's location with this PR's wider condition — if maintainers prefer that layer. Either way, fixing #37946 requires covering the no-tool-call empty case that #33899 currently skips.

github-actions · 2026-08-22T22:05:12Z

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

The PR was created more than 1 month ago
The PR had fewer than 2 positive reactions
Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.

codeg-dev · 2026-08-22T22:30:35Z

This remains an active fix for the still-open #37946. I rebased the branch onto the current dev (411 upstream commits), resolved the stale branch state cleanly, and re-ran the relevant validation on the rebased tree: 46/46 message-v2 tests pass, packages/opencode typecheck passes, and Prettier is clean. The related #33899 was also cleanup-closed without merge and does not cover #37946’s no-tool-call empty assistant shape. Requesting maintainer review/reopen.

This was referenced Jul 22, 2026

fix(provider): ensure non-empty assistant content for openai-compatible (#33280) #33899

Closed

Aborted assistant turn persisted with zero content bricks the session: empty assistant message replayed to provider (400 "must not be empty") #37946

Closed

sowervids mentioned this pull request Jul 23, 2026

Unfinished assistant scaffold persists after prompt setup failure #38425

Closed

github-actions Bot closed this Aug 22, 2026

github-actions Bot added the automated-pr-cleanup label Aug 22, 2026

Navigation Menu

Repository navigation

fix(provider): inject placeholder text for empty assistant wire messages on openai-compatible - #38270

fix(provider): inject placeholder text for empty assistant wire messages on openai-compatible#38270
codeg-dev wants to merge 1 commit into
anomalyco:devfrom
codeg-dev:codeg/fix-empty-assistant-wire

codeg-dev commented Jul 22, 2026

Uh oh!

github-actions Bot commented Jul 22, 2026

Uh oh!

codeg-dev commented Jul 22, 2026

Uh oh!

github-actions Bot commented Aug 22, 2026

Uh oh!

codeg-dev commented Aug 22, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

codeg-dev commented Jul 22, 2026

Issue for this PR

Type of change

What does this PR do?

How did you verify your code works?

Screenshots / recordings

Checklist

Uh oh!

github-actions Bot commented Jul 22, 2026

Uh oh!

codeg-dev commented Jul 22, 2026

Uh oh!

github-actions Bot commented Aug 22, 2026

Uh oh!

codeg-dev commented Aug 22, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant