The response-repair path builds an assistant message that can never carry reasoning content #699

New issue

Closed

opened 2026-08-13 19:46:21 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-13 19:46:21 +00:00

Member

Slice of #678, filed so a fix can land on the half that needs no live request while the half that does stays open there.

The half this closes

internal/community/proxy.go builds an assistant message in two places. The tool-call path copies ReasoningContent. The response-repair path had no field for it at all, so a repair round could only ever send the zero value, whatever the model returned.

Quail identified this on #678 as a third mechanism, independent of the trace that issue was filed from:

Reasoning content from that response is discarded unconditionally. Any repair attempt against a thinking-mode model builds an assistant message that can never carry the field, and DeepSeek rejects the next request for the same reason.

Two build sites, one field, no reason for the difference. Preserving what the model returned is not a judgement about what to synthesise, which is what makes it separable.

internal/community/repairreasoning_test.go already asserted the bug as it ships and named what to change. Inverted rather than deleted.

What this does not close, and why it stays on #678

Whether DeepSeek accepts "reasoning_content": "". Under omitempty an empty string and an absent key are the same bytes, so a model that genuinely returns no reasoning still produces a request the API refuses. Deciding that needs one live request to evaluation/deepseek-v4-flash with an assistant message carrying an empty reasoning_content, which is an Ops action. #678 remains open on it.

Acceptance

A repair round against a thinking-mode model sends the reasoning content the model returned.
Verified by mutation: with the field forced to "" the test fails, and the package compiles in that run rather than failing to build.

Next owner

Engineer. Closed by the pull request that lands the change.

Slice of https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/678, filed so a fix can land on the half that needs no live request while the half that does stays open there. ## The half this closes `internal/community/proxy.go` builds an assistant message in two places. The tool-call path copies `ReasoningContent`. The response-repair path had no field for it at all, so a repair round could only ever send the zero value, whatever the model returned. Quail identified this on #678 as a third mechanism, independent of the trace that issue was filed from: > Reasoning content from that response is discarded unconditionally. Any repair attempt against a thinking-mode model builds an assistant message that can never carry the field, and DeepSeek rejects the next request for the same reason. Two build sites, one field, no reason for the difference. Preserving what the model returned is not a judgement about what to synthesise, which is what makes it separable. `internal/community/repairreasoning_test.go` already asserted the bug as it ships and named what to change. Inverted rather than deleted. ## What this does not close, and why it stays on #678 Whether DeepSeek accepts `"reasoning_content": ""`. Under `omitempty` an empty string and an absent key are the same bytes, so a model that genuinely returns no reasoning still produces a request the API refuses. Deciding that needs one live request to `evaluation/deepseek-v4-flash` with an assistant message carrying an empty `reasoning_content`, which is an Ops action. **#678 remains open on it.** ## Acceptance - A repair round against a thinking-mode model sends the reasoning content the model returned. - Verified by mutation: with the field forced to `""` the test fails, and the package compiles in that run rather than failing to build. ## Next owner Engineer. Closed by the pull request that lands the change.

coilyco-ops added the

autonomy

headless

label

2026-08-13 19:46:21 +00:00

coilyco-ops referenced this issue from a commit

2026-08-13 19:47:58 +00:00

fix(proxy): carry reasoning content through the response-repair path

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 19:48:41 +00:00

fix(proxy): carry reasoning content through the response-repair path #700

coilyco-ops referenced this issue