You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Assistant messages with no provider content permanently wedge sessions on strict providers (Kimi 400 must not be empty) #53571
On OpenCode v1 (historically verified on 1.18.34, Windows), a session becomes permanently unusable after a reply stream dies before producing content (e.g. app quit mid-stream, provider error mid-turn). Every subsequent send fails:
APIError 400: the message at position N with role 'assistant' must not be empty
The position stays constant across retries. The session can never send again.
Two compounding defects were identified in the V1 path:
In packages/opencode/src/session/message-v2.ts, toModelMessagesEffect only guards assistantMessage.parts.length > 0 before result.push. Parts with no provider content (step-start, empty-text parts) satisfy that check, allowing a metadata-only shell to become an assistant message with no content.
Failed reply attempts are persisted as new assistant messages carrying the error, so retries add more empty assistants and repeat the provider rejection.
The local proposed fix emits an assistant message only when it contributes provider content: non-empty text, a tool call, or non-empty reasoning. Signed-reasoning separator shapes must remain eligible. PR #53575 carried a guard and fixture tests, but was process-closed and was not technically accepted. This report has not been reproduced on V2 and is not evidence that the V2 request builder has the same defect.
Plugins
Not isolated in the original V1 report; the cited mechanism is core message conversion.
OpenCode version
1.18.34 (historical reproduction).
Steps to reproduce
Start a V1 session on a strict provider, such as Kimi's coding API.
Interrupt a reply before first content, for example by quitting the app or terminating the response stream.
Send another message. The provider returns 400 ... role 'assistant' must not be empty; further retries repeat the same position.
Screenshot and/or share link
Exact error above; no private session history shared.
Retrospective correction: I have updated the closed report to the current Bug Report field names, including the required Description, in response to the template bot. The original closure was the 72-hour template-compliance automation, not a demonstrated technical fix. PR #53575 was likewise process-closed.
This is a historical V1 reproduction. In light of the maintainer's V1 retirement notice on #49386, I am not requesting reopening or refiling the same V1 report without a V2 reproduction. The V2 OpenAI Chat envelope guard reported separately is a different mechanism; it is not evidence that this empty-assistant defect survived the rewrite.
Activity
github-actions commentedon Oct 6, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
Please edit this issue to address the above within 72 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
If you believe this was flagged incorrectly, please let a maintainer know.
fix(session): drop assistant messages with no provider content (empty…
github-actions commentedon Oct 9, 2026
This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 72-hour window.
Feel free to open a new issue that follows our issue templates.
mradwankhalil commentedon Oct 14, 2026
Retrospective correction: I have updated the closed report to the current Bug Report field names, including the required Description, in response to the template bot. The original closure was the 72-hour template-compliance automation, not a demonstrated technical fix. PR #53575 was likewise process-closed.
This is a historical V1 reproduction. In light of the maintainer's V1 retirement notice on #49386, I am not requesting reopening or refiling the same V1 report without a V2 reproduction. The V2 OpenAI Chat envelope guard reported separately is a different mechanism; it is not evidence that this empty-assistant defect survived the rewrite.