v2: empty reasoning-only response is recorded as successful completion

[kitlangton]

Summary

V2 records a reasoning-only assistant response with no visible text and no tool calls as a successful execution. Downstream clients consequently receive neither an answer nor a failure they can surface, even though the user's turn produced no usable output.

This was observed twice consecutively in a production embedded V2 session using opencode/gpt-5.6-sol.

Environment

• opencode version: V2 commit b4be28d4c3d0e4789ac62054ff647f6a432e1dfe (the embedded runtime does not expose a version executable in this deployment)
• OS: Linux 6.12.93, x86_64
• Terminal: N/A; embedded server used by OpenCode Agent
• Shell: N/A for the failing model turns
• Install/channel: V2 production deployment embedded in OpenCode Agent
• Active plugins: OpenCode Agent registers its agent definition and scoped tools through the V2 plugin API
• Provider/model: opencode/gpt-5.6-sol, default variant

Reproduction

1. Start a V2 session using opencode/gpt-5.6-sol through the embedded server.
2. Submit a normal user question that should produce a textual response.
3. Observe a provider response containing reasoning lifecycle events but no assistant text or tool calls.
4. Observe V2 emit session.step.ended.1 with finish: "stop", followed by session.execution.succeeded.1.

This occurred on the initial turn and again on a follow-up in the same session. The relevant redacted event sequences were:

19:48:41 session.step.started.1
19:48:41 session.reasoning.started.1
19:48:42 session.reasoning.ended.1     text=""
19:48:42 session.step.ended.1          finish="stop", output=6, reasoning=62
19:48:43 session.execution.succeeded.1

19:54:56 session.step.started.1
19:54:56 session.reasoning.started.1
19:54:56 session.reasoning.ended.1     text=""
19:54:57 session.step.ended.1          finish="stop", output=6, reasoning=11
19:54:57 session.execution.succeeded.1

Neither step emitted text content or a tool call. The six output tokens did not produce any publishable assistant content.

Expected Behavior

A terminal assistant step with no visible text and no tool calls should not silently count as a successful user turn.

V2 should either:

• retry the empty provider completion with a small bounded retry policy; or
• terminate with a typed empty-response failure that clients can publish to the user.

The invariant should be based on usable assistant output, not token count alone, because these responses reported six output tokens while producing no visible content.

Actual Behavior

V2 emitted session.execution.succeeded.1. The downstream Slack projection therefore stopped its typing/progress state without publishing an answer or an error. From the user's perspective, the agent acknowledged the message and then silently stopped.

The surrounding runtime boundaries were healthy:

• Slack ingress received and admitted both inputs.
• The durable AgentSession mailbox accepted both inputs.
• The embedded V2 session ran both steps to terminal events.
• Projection cursors caught up.
• The service had one runtime owner, no unprocessed queue entries, and no persistence or transport defect.

This makes the narrow failing boundary the V2/provider completion contract: a response with no usable assistant output is accepted as successful.

Additional Context

Related: #31430 documented the same broad symptom for V1 with Bedrock Mantle and GPT 5.5. That issue was closed as an upstream provider bug because the provider returned an empty response marked completed.

This report is distinct and V2-specific:

• it reproduces on the V2 event model;
• it uses the hosted opencode provider and gpt-5.6-sol, not Bedrock Mantle;
• the response contains reasoning and nonzero output-token accounting, but still no usable assistant output; and
• V2's session.execution.succeeded.1 prevents downstream clients from distinguishing this from a valid completed answer.

Even if the provider response is upstream behavior, V2 needs a defensive terminal-state contract so clients do not silently drop a user turn.

Reproducibility: observed on two consecutive prompts in the same production session. Later turns in that session could execute tools, showing that the session, provider credentials, and runtime remained operational.

[rasitakyol]

I can take this on the v2 branch as a scoped defensive fix. I plan to classify a successful provider stream with no visible text and no tool call as the existing provider.invalid-output terminal failure, rather than adding an automatic retry policy. The regression coverage will include reasoning-only, whitespace-only text, and a completely empty successful stream. Please let me know if you prefer bounded retry semantics instead.

[rasitakyol]

Draft implementation: #37379 (base: v2). The PR uses the typed provider.invalid-output approach described above.