DeepSeek Harness MALFORMED_RESPONSE: refusal stop reason

A 24-character Chinese operations instruction — "today's daily K-line data is updated, you can run the scheduled task early" — streamed reasoning normally, with the model even restating the task, and then the stream ended with stop_reason: refusal while the UI reported "this turn failed / MALFORMED_RESPONSE". That error code is easy to read as "the response was truncated" or "the model rejected you", but semantically it says exactly one thing: the client does not recognize this stop reason (#11337).

DeepSeek Harness: Layer 1: MALFORMED_RESPONSE means "I do not recognize this"

It is the client's classification of the response stream, not a transport error and not a moderation verdict.

1. Read the full text: DeepSeek Messages stream: unsupported stop reason refusal, with code MALFORMED_RESPONSE.
2. Read the stream contents: first a reasoning block where the model correctly restates the task and plans which scheduled item to run.
3. Then a finish block whose reason.kind is error and whose failure.message is the sentence above.
4. In other words: content production succeeded, and the failure happened in the closing stage.
5. So "malformed" here means "I have no handler for this end reason", not "the payload is broken".

DSH plugin: Layer 2: stopReason() knows only four values

The adapter handles end_turn, stop_sequence, tool_use, and max_tokens only; everything else goes to malformed(), and refusal lands in "everything else".

1. Follow the arrival path: message_delta hands stop_reason to stopReason().
2. Read the branches: the four known values each map somewhere, and all others go to malformed().
3. The community ran that function in an isolated environment: input refusal produced exactly the error you see.
4. Conclusion: the client behavior is predictable and deterministic, no guessing required.
5. This is also the only part of the article that yields a definite conclusion.

DeepSeek Harness: Layer 3: whose semantics is refusal anyway

It is a stop reason from upstream; the client classifies it as an error but cannot explain why upstream sent it.

1. Anthropic's documentation lists refusal as a legal Messages stop reason, but that document describes Claude.
2. It does not establish DeepSeek's contract, nor prove whether this particular refusal was reasonable.
3. The reporter's input contains no violence, self-harm, illegal, sexual, personal-data, or political content; it is a scheduling instruction.
4. The reporter's hypothesis is that a post-hoc safety classification read "run the scheduled task early" as an external action — a hypothesis, not a conclusion.
5. Stop here: the only half that belongs in documentation is the client mapping.

DSH Plugin: The boundary between certain and uncertain

Keeping the two kinds of conclusion separate prevents describing a client defect as a model problem and prevents judging on the provider's behalf.

DeepSeek Harness: How to handle this class of error

What the client side should do is "preserve the upstream reason and map it to a distinct state", not flatten every unknown value into one error code.

1. Keep the original upstream stop_reason value in the normalized result; do not drop it.
2. If refusal is a legal value for that provider, map it to a distinct "model declined" state instead of MALFORMED_RESPONSE.
3. Give the user a readable explanation without exposing internal reasoning.
4. Do not retry the same rejected request indefinitely.
5. Add a regression test: a stream with a valid reasoning block followed by stop_reason: "refusal".
6. Investigating provider behavior is a separate task; the two can run in parallel and should not block each other.

DSH plugin: What to collect when reproducing

Enough information is enough; do not bring credentials or business data into it.

1. A redacted message_delta event, including stop_details if present.
2. The client version and the provider version.
3. The result of a second run with the same input, to judge whether it reproduces reliably.
4. When the event happened and whether it was retried.
5. Explicitly exclude credentials, private prompts, and session identifiers.

A reusable judgment framework

When a report says "an unknown value was treated as an error", ask three questions first: who produced the value, how does the client map it, and what do the docs promise.

1. Who produced it: an upstream response field or a client inference. Here it is upstream's stop_reason.
2. How the client handles it: is there an explicit branch, and where do unknown values land. Here they land in malformed().
3. What the docs promise: does that provider publicly list the value. Here only Claude's docs mention it.
4. If all three still leave "why did upstream send it" unanswered, do not overreach when drawing conclusions.
5. The framework also applies to other unsupported ... errors: most indicate a mapping gap, not corrupted data.

Cautions

Keep the two halves of the story separate in every report.

1. Do not treat MALFORMED_RESPONSE as a network problem. It appears at stream teardown, not in transport.
2. Do not infer a content violation from it. The client has no authority to interpret.
3. Do not retry the same message repeatedly. First confirm whether it reproduces reliably.
4. Do not treat Anthropic's docs as DeepSeek's contract. The same field name may mean different things across providers.
5. Separate the two halves in a report. "Client mapping gap" and "provider refusal reason" must be written separately, or maintainers cannot locate the problem.

If your message is not unsupported stop reason, it belongs to another teardown problem — check the full structure of the finish block.

If it really is unsupported stop reason but the value is not refusal, the logic is identical: map the gap first, then discuss upstream behavior.See DeepSeek Harness thinking-only output: empty stop succeeds for the related case.