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

[Oloompa]

Description

A turn was aborted mid-stream (the TUI had frozen after an OS suspend/resume, so I aborted). OpenCode persisted the aborted assistant message with error: MessageAbortedError and only step-start / reasoning / patch parts — no text, no tool call.

From then on, every subsequent prompt replays this message in the history as an assistant message with empty content. Moonshot (via OpenRouter) rejects the whole request:

[Moonshot AI] Invalid request: the message at position 29 with role 'assistant' must not be empty (400)

It snowballs: each failed retry persists another empty assistant message with error: APIError, so the failing position advances (29 → 30 → …) and the session is permanently unusable. I had to manually delete the artifact messages from opencode.db to recover the session.

Expected behavior: an aborted/errored assistant turn with no serializable content should either not be persisted, or be filtered out when building the model messages (the assistant-side equivalent of the guard requested in #31046 for empty text parts).

Steps to reproduce

1. Session with a strict provider (openrouter / moonshotai/kimi-k3)
2. Abort a turn while the model is still in reasoning, before any text or tool part is emitted
3. Send any new message → 400 "must not be empty"; each retry fails the same way and appends a new empty artifact message

Environment

• OpenCode version: 1.18.3
• OS: Linux
• Plugins: oh-my-opencode

Related

• "Invalid request: the message at position 64 with role 'assistant' must not be empty" with Kimi K3 #37887 (same symptom with Kimi K3, auto-closed for template non-compliance)
• Empty text parts in assistant message history cause 422 on strict providers #31046 (empty text parts — different root cause)
• Dead loop: infinite empty assistant messages (tokens=0) after tool call with empty text #28507 (empty assistant message loop after tool call)

[github-actions]

This issue might be a duplicate of or closely related to existing issues not already mentioned. Please check:

• Aborted provider stream recorded as clean stop (finish=unknown, zero usage, no text) — subagent returns empty with no error #37852: Aborted provider stream recorded as clean stop (finish=unknown, zero usage, no text) — same trigger (stream abort during reasoning phase), though that issue focuses on the subagent returning empty with no error rather than the 400 on replay. The two may share the same root fix.
• v2: empty reasoning-only response is recorded as successful completion #37372: v2: empty reasoning-only response is recorded as successful completion — similar in that a reasoning-only turn with no text is accepted as success, leading to a zero-content assistant message persisted in history.

[codeg-dev]

I reproduced the strict-provider replay failure described here and opened #38270 with a targeted fix.

The patch post-processes the final ModelMessage list for @ai-sdk/openai-compatible: if an assistant wire message has no non-empty text, it prepends a single-space text part. This covers the aborted step-start / reasoning-only shape from this issue, empty-text-only messages, tool-call-only turns, and per-step pieces created after step-start splitting without dropping tool-call or reasoning history.

Validation includes 7 regression cases (43/43 tests passing), clean typecheck, and a replay of a previously bricked Kimi K3 session where the follow-up request now succeeds.

This is intentionally broader than #33899: that PR only handles messages with tool calls and therefore leaves this issue's no-tool-call aborted reasoning-only shape unchanged.