DeepSeek thinking-mode multi-turn fails: reasoning_content not echoed back (provider 400)

[oxoxDev]

Summary

DeepSeek (and DeepSeek-via-aggregator) requests in thinking mode fail on multi-turn with a provider 400 Bad Request:

... API error (400 Bad Request): {"error":{"message":"The `reasoning_content` in the thinking mode must be passed back ..."}}

The request builder does not echo the assistant's prior-turn reasoning_content back in the next request's message history, which DeepSeek's thinking mode requires.

Impact

~171 events across several Sentry issues (self-hosted tauri-rust, error_type:inference), second-largest contributor to the generic chat-error cluster. Until fixed, these turns fail; the user now sees an actionable "provider rejected the request" message (added in the classifier-hardening PR for #3119) instead of a bare apology — but the turn still cannot complete.

Likely site

• src/openhuman/inference/provider/compatible.rs — OpenAI-compatible request builder.
• src/openhuman/context/pipeline.rs / context/microcompact.rs — where assistant turns are assembled into request history (existing reasoning_content handling lives here).

The builder must re-attach reasoning_content to prior assistant messages when the active model is in thinking mode.

Acceptance

• Multi-turn DeepSeek thinking-mode conversation completes without the reasoning_content must be passed back 400.
• Round-trip preserved across compaction/microcompact.
• Unit coverage for the request-assembly path.

Related

• Surfaced while root-causing Some users receive "Something went wrong" error message during normal chat interactions #3119 / Something went wrong" error on app chat (multiple users reported the same) #3092 (generic "Something went wrong" chat errors). The classifier-hardening PR for Some users receive "Something went wrong" error message during normal chat interactions #3119 routes this 400 to an actionable message but does not fix the underlying roundtrip.

[oxoxDev]

Closing as already fixed on main (v0.57.5).

This issue was filed while root-causing the generic chat-error cluster (#3119 / #3092), on the hypothesis that the OpenAI-compatible request builder never echoes a prior assistant turn's reasoning_content back to DeepSeek thinking mode. On re-checking main, that round-trip is already implemented — and was shipped across four PRs:

PR	Release	What
#2818 (closes #2800)	v0.57.2-staging	preserve reasoning_content in multi-turn thinking-model conversations
#2876	v0.57.2-staging	replay DeepSeek reasoning_content on tool-call turns (TAURI-RUST-4KB)
#2918	v0.57.4	replay reasoning_content across native tool-call turns to prevent DeepSeek 400s
#3124	v0.57.5	accept the reasoning field alias for thinking-mode providers

The machinery is present and tested on main: NativeMessage.reasoning_content (omitted via skip_serializing_if when absent), convert_messages_for_native re-attaches it from the stored assistant turn, the dispatcher serializes it back onto the outbound message, and there are seven unit tests in compatible_tests.rs covering the round-trip (incl. tool-call turns, omit-when-absent, and the intentional strip when an assistant message collapses to plain text).

Sentry confirms the fix landed: every reasoning_content must be passed back 400 event comes from a pre-fix client. Release distribution on the affected issues:

• TAURI-RUST-4K9 (735 events): 100% 0.56.0
• TAURI-RUST-4KA (267 events): 100% 0.56.0
• TAURI-RUST-17Z (93 events): 100% 0.54.0
• TAURI-RUST-2G / 2F: pre-fix, last seen 2026-05-29 (already resolved)

Zero events from 0.57.2 or newer. The recent lastSeen timestamps are stale 0.54.0/0.56.0 binaries still running in the wild, not new failures against current main.

The classifier-hardening PR for #3119 (#3199) routes any residual 400 to an actionable "provider rejected the request" message, so even an old client degrades gracefully. No code change needed here.

Superseded by #2818 / #2876 / #2918 / #3124.