fix: replay DeepSeek reasoning_content on tool-turn history by snowzlm · Pull Request #71146 · openclaw/openclaw

snowzlm · 2026-04-24T15:03:08Z

Problem

Under DeepSeek V4 thinking mode, when historical assistant tool-call messages lack the reasoning_content field, the API returns a 400 error:

The reasoning_content in the thinking mode must be passed back to the API.

Root Cause

convertMessages does not generate a reasoning_content field when converting assistant tool-call history to OpenAI format. DeepSeek thinking mode strictly requires this field to be present.

Fix

In buildOpenAICompletionsParams, after convertMessages, insert injectDeepSeekReasoningReplay to inject reasoning_content as a fallback for DeepSeek model assistant tool-call messages.

Fallback priority (highest to lowest):

Existing non-empty reasoning_content → keep as-is
reasoning field → copy
reasoning_text field → copy
Replay signature key content extraction
Assistant content string → copy
None of the above → empty string "" (verified safe against live API)

Only applied to models with provider=deepseek or baseUrl containing deepseek.com.

Verification

Unit tests cover all 5 fallback paths
Production dry-run: 1493 tool-turns, missingAfterPatch: 0
Production live test: 0 errors after applying the patch

This PR injects a reasoning_content fallback into assistant tool-call messages before they are sent to DeepSeek thinking-mode APIs, preventing 400 errors caused by the field being absent. The core logic and test coverage are solid, but there is one gap: the documented Priority 6 "empty string fallback" is never actually written to the message when all other content sources are absent (content: null, no thinking block, no reasoning/reasoning_text fields), so the original 400 can still be triggered for cross-model history with no text.

P1: When reasoning_content is absent and all fallbacks yield nothing (e.g., an OpenAI tool-call turn with content: null), the field stays absent and DeepSeek still returns 400. A final record.reasoning_content = record.reasoning_content ?? \"\"; after line 1794 would close this gap.
P2: extractReplayReasoningContent returns early on the first non-empty replay-signature key, leaving any subsequent matching keys out of keysToDelete and unsanitized in the outgoing message.

Confidence Score: 4/5

Safe to merge after addressing the missing empty-string fallback, which can still trigger a 400 for cross-model tool-call history with no text content.

A P1 gap exists: the final fallback to "" is documented in the PR description but never assigned in code, leaving the original 400 possible for tool-call turns without any text content. All other logic is correct and the test suite covers the primary paths.

src/agents/openai-transport-stream.ts — specifically the end of injectDeepSeekReasoningReplay where the "" fallback is missing.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/agents/openai-transport-stream.ts
Line: 1792-1795

Comment:
**Missing empty-string fallback when all content sources are absent**

The PR description explicitly states Priority 6 is "None of the above → empty string `""` (verified safe against live API)", but the implementation never assigns `""`. If `record.reasoning_content` is absent (which is the whole problem being fixed), `record.reasoning` / `record.reasoning_text` are absent, no replay-signature key is present, and `record.content` is `null` or not a string (common for OpenAI tool-call messages with `content: null`), the function returns without setting `reasoning_content` at all. The field remains absent and DeepSeek will still return the 400 error this PR is meant to prevent. A final unconditional assignment of `record.reasoning_content = record.reasoning_content ?? "";` after the last `if` block would close the gap.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/agents/openai-transport-stream.ts
Line: 1723-1737

Comment:
**Incomplete `keysToDelete` when multiple replay-signature keys exist**

`extractReplayReasoningContent` early-returns as soon as it finds the first non-empty replay-signature key, leaving any subsequent matching keys out of the returned `keysToDelete` array. Those keys will survive the cleanup loop and be forwarded to the DeepSeek API. Concretely, if a message had two keys whose names satisfy `parseReplayReasoningSignatureKey` (e.g., two `rs_`-prefixed reasoning blocks), only the first and any empty-valued predecessors are deleted; the rest are orphaned. The fix is to collect all matching keys first, then pick the first non-empty value.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix: normalize DeepSeek reasoning replay..." | Re-trigger Greptile}

greptile-apps · 2026-04-24T15:06:36Z

+    if (typeof record.content === "string" && record.content.trim().length > 0) {
+      record.reasoning_content = record.content;
+    }
+  }


Missing empty-string fallback when all content sources are absent

The PR description explicitly states Priority 6 is "None of the above → empty string "" (verified safe against live API)", but the implementation never assigns "". If record.reasoning_content is absent (which is the whole problem being fixed), record.reasoning / record.reasoning_text are absent, no replay-signature key is present, and record.content is null or not a string (common for OpenAI tool-call messages with content: null), the function returns without setting reasoning_content at all. The field remains absent and DeepSeek will still return the 400 error this PR is meant to prevent. A final unconditional assignment of record.reasoning_content = record.reasoning_content ?? ""; after the last if block would close the gap.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/agents/openai-transport-stream.ts Line: 1792-1795 Comment: **Missing empty-string fallback when all content sources are absent** The PR description explicitly states Priority 6 is "None of the above → empty string `""` (verified safe against live API)", but the implementation never assigns `""`. If `record.reasoning_content` is absent (which is the whole problem being fixed), `record.reasoning` / `record.reasoning_text` are absent, no replay-signature key is present, and `record.content` is `null` or not a string (common for OpenAI tool-call messages with `content: null`), the function returns without setting `reasoning_content` at all. The field remains absent and DeepSeek will still return the 400 error this PR is meant to prevent. A final unconditional assignment of `record.reasoning_content = record.reasoning_content ?? "";` after the last `if` block would close the gap. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-04-24T15:06:37Z

+function extractReplayReasoningContent(record: Record<string, unknown>): {
+  content?: string;
+  keysToDelete: string[];
+} {
+  const keysToDelete: string[] = [];
+  for (const [key, value] of Object.entries(record)) {
+    if (!parseReplayReasoningSignatureKey(key)) {
+      continue;
+    }
+    keysToDelete.push(key);
+    if (typeof value === "string" && value.trim().length > 0) {
+      return { content: value, keysToDelete };
+    }
+  }
+  return { keysToDelete };


Incomplete keysToDelete when multiple replay-signature keys exist

extractReplayReasoningContent early-returns as soon as it finds the first non-empty replay-signature key, leaving any subsequent matching keys out of the returned keysToDelete array. Those keys will survive the cleanup loop and be forwarded to the DeepSeek API. Concretely, if a message had two keys whose names satisfy parseReplayReasoningSignatureKey (e.g., two rs_-prefixed reasoning blocks), only the first and any empty-valued predecessors are deleted; the rest are orphaned. The fix is to collect all matching keys first, then pick the first non-empty value.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/agents/openai-transport-stream.ts Line: 1723-1737 Comment: **Incomplete `keysToDelete` when multiple replay-signature keys exist** `extractReplayReasoningContent` early-returns as soon as it finds the first non-empty replay-signature key, leaving any subsequent matching keys out of the returned `keysToDelete` array. Those keys will survive the cleanup loop and be forwarded to the DeepSeek API. Concretely, if a message had two keys whose names satisfy `parseReplayReasoningSignatureKey` (e.g., two `rs_`-prefixed reasoning blocks), only the first and any empty-valued predecessors are deleted; the rest are orphaned. The fix is to collect all matching keys first, then pick the first non-empty value. How can I resolve this? If you propose a fix, please make it concise.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a0a8a27f99

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-04-24T15:08:59Z

+    if (typeof value === "string" && value.trim().length > 0) {
+      return { content: value, keysToDelete };
+    }


Delete all replay-signature keys before returning content

extractReplayReasoningContent returns as soon as it finds the first non-empty replay value, so any later replay-signature keys on the same assistant tool-call message are never collected into keysToDelete. This can happen when a single turn contains multiple reasoning replay items, and it leaves stray JSON-encoded keys in the outgoing message payload, which defeats the scrub step and can still trigger DeepSeek request validation errors on replayed history.

Useful? React with 👍 / 👎.

Addresses Greptile review feedback: P1: When all fallback sources are absent (e.g., OpenAI tool-call with content: null replayed against DeepSeek), reasoning_content remained undefined, still triggering 400. Add unconditional empty-string fallback. P2: extractReplayReasoningContent early-returned on the first non-empty replay-signature key, leaving subsequent matching keys unsanitized. Collect all matching keys before picking the first non-empty value.

steipete · 2026-04-24T15:24:21Z

Thanks for the contribution. Closing this as superseded by #71105, which has now landed the DeepSeek V4 catalog/default update plus the provider-owned reasoning_content replay fix for DeepSeek V4 thinking/tool turns.

The landed path keeps the behavior inside the DeepSeek plugin boundary, preserves legacy deepseek-chat / deepseek-reasoner entries, and was verified with live DeepSeek V4 Flash/Pro calls.

snowzlm added 4 commits April 24, 2026 18:45

test: cover DeepSeek reasoning_content replay on tool turns

a51a872

fix: replay DeepSeek reasoning on tool-turn history

5dabdd9

fix: map replay signatures into DeepSeek reasoning

a7cf1ed

fix: normalize DeepSeek reasoning replay aliases

a0a8a27

openclaw-barnacle Bot added agents Agent runtime and tooling size: M labels Apr 24, 2026

greptile-apps Bot reviewed Apr 24, 2026

View reviewed changes

chatgpt-codex-connector Bot reviewed Apr 24, 2026

View reviewed changes

steipete closed this Apr 24, 2026

flofrie mentioned this pull request Apr 30, 2026

[Feature]: Allow per-model setting for Deepseek reasoning_content fix #75105

Closed

Svtter mentioned this pull request May 4, 2026

[Bug]: chat_messages_to_native() drops reasoning_content for plain-text assistant messages zeroclaw-labs/zeroclaw#6233

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix: replay DeepSeek reasoning_content on tool-turn history#71146

fix: replay DeepSeek reasoning_content on tool-turn history#71146
snowzlm wants to merge 5 commits into
openclaw:mainfrom
snowzlm:fix/deepseek-thinking-replay

snowzlm commented Apr 24, 2026

Uh oh!

greptile-apps Bot commented Apr 24, 2026

Uh oh!

greptile-apps Bot Apr 24, 2026

Uh oh!

greptile-apps Bot Apr 24, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot Apr 24, 2026

Uh oh!

steipete commented Apr 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

snowzlm commented Apr 24, 2026

Problem

Root Cause

Fix

Verification

Related

Uh oh!

greptile-apps Bot commented Apr 24, 2026

Greptile Summary

Confidence Score: 4/5

Uh oh!

greptile-apps Bot Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

steipete commented Apr 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants