In one session developing for awhile with DeepSeek-V4-Flash, received "all messages must have non-empty content" errors #31971

Activity

1. github-actions

   assigned

   StarpTech

   on Jun 12, 2026
2. github-actions commented on Jun 12, 2026

   

   github-actionsBot

   on Jun 12, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • DeepSeek thinking mode: reasoning_content not passed back for tool call turns, causing 400 errors #24722: DeepSeek thinking mode causing 400 errors — related to missing/empty content in message history sent to DeepSeek API, which may share the same root cause as the "all messages must have non-empty content" error you're seeing.
3. DXXS commented on Jun 12, 2026

   

   DXXS

   on Jun 12, 2026

   Author

   More actions

   I had reported a somewhat similar blockage with a 'reasoning_content' error in a previous version of opencode in #24870 but this appears to be a totally different error message. If they're actually the same issue, then IMO the code should be providing the same error.
4. Oxygen56 commented on Jun 24, 2026

   

   Oxygen56

   on Jun 24, 2026

   More actions

   Confirming this bug with additional reproduction data

   I can confirm this exact issue from an independent reproduction. Sharing detailed forensic analysis below.

   Reproduction Environment

   • Opencode version: v1.17.9 (runtime), CLI v0.3.28
   • Provider: DeepSeek API (not limited to V4-Flash — also reproduces on other DeepSeek models)
   • Platform: Multica agent platform using Opencode as the LLM runtime

   Root Cause Analysis

   The DeepSeek adapter constructs a messages array from the conversation context. When the context grows large (50+ messages in a multi-turn coding session with long comments/threads), at least one message in the array ends up with empty content (content: ""). DeepSeek API rejects this with:

   invalid_request_error: all messages must have non-empty content
   

   This is NOT intermittent — once the context grows past a threshold where empty-content messages appear, every subsequent API call in the same session fails, effectively bricking the session.

   Exact Trigger in Our Case

   1. A coding agent working on a complex issue submitted a ~7,800-character research report as a comment
   2. The main agent (using Opencode + DeepSeek as runtime) attempted to process this comment
   3. Within 8 seconds of the long comment being posted, the API returned messages.55: all messages must have non-empty content
   4. Subsequent retries hit the same error at different indices (messages.47, messages.625 — the index varies by context size)
   5. New sessions work fine initially, consistent with your observation

   Clinical Timeline (2026-06-24 UTC)

   Time	Event
   10:17:12	Agent posts a 7,822-character research report comment
   10:17:20	DeepSeek API returns messages.55: all messages must have non-empty content
   10:39:23	Retry attempt — same error at messages.47
   10:41:00	Another retry — same error at messages.47

   Suspected Code Path

   The issue likely originates in the message normalization/transformation pipeline before the API call is dispatched. Empty content messages can arise from:

   1. Normalization dropping content: Functions like normalizeMessages() may strip text parts from messages that have reasoning blocks but no text content, leaving a message with content: ""
   2. Thinking mode artifacts: DeepSeek's thinking mode can produce assistant messages where reasoning_content exists but text content is empty. If the round-trip normalization preserves reasoning but drops the empty text part, and the API still requires non-empty content, this triggers the error
   3. Context compaction: Long sessions trigger compaction, which may produce messages with empty content fields in edge cases

   Recommended Fix

   Add a filtering step in the DeepSeek adapter/provider path that removes messages with empty/null content from the messages array before dispatching to the API. This is a defensive safety net — regardless of which upstream code path produces the empty message, the adapter should never send it to DeepSeek.

   In pseudocode:

   // Before sending to DeepSeek API
   messages = messages.filter(m => {
     if (typeof m.content === 'string') return m.content.length > 0;
     if (Array.isArray(m.content)) return m.content.length > 0;
     return false;
   });

   This is a ~3-line change with zero API surface impact. It addresses the symptom regardless of which specific upstream path (normalization, compaction, thinking mode round-trip, etc.) produced the empty message.

   Related Fixes That Don't Fully Cover This

   • PR fix: preserve empty reasoning_content for DeepSeek V4 thinking mode #24146 (preserve empty reasoning_content): Fixes one source of empty content but only in thinking mode
   • PR fix: preserve existing reasoning_content on second interleaved pass (#24146 follow-up) #24428 (second interleaved pass): Fixes a regression from fix: preserve empty reasoning_content for DeepSeek V4 thinking mode #24146
   • PR fix(provider): complete DeepSeek reasoning_content round-trip for multi-turn conversations #24250 (reasoning_content round-trip): Broader fix but still scoped to reasoning content

   These are all reasoning-content-specific fixes. A generic empty-content filter at the API dispatch boundary would catch all sources of this class of error, including non-reasoning cases.

   Workaround for Users

   Until this is fixed upstream, users can work around by starting a fresh session when the error occurs — the error is session-state-dependent, and new sessions start with clean context.

   ---

   This analysis was performed on the Multica platform (multica-ai/multica). The Opencode runtime is used as the LLM execution backend for coding agents.
5. github-actions commented on Aug 24, 2026

   

   github-actionsBot

   on Aug 24, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
6. github-actions

   closed this as not plannedon Aug 24, 2026