[Bug] Benign Chinese ops prompt → stream ends with stop reason "refusal" → client reports MALFORMED_RESPONSE (deepseek-flash)

[yanwenzong1-pixel]

Summary

A benign operational instruction (24 Chinese characters, no sensitive content) caused the Messages-style stream to terminate with an upstream stop_reason of refusal, which the client surfaces as a hard error:

本轮运行失败  DeepSeek Messages stream: unsupported stop reason refusal   MALFORMED_RESPONSE

The model had already emitted a reasoning block (it clearly understood the task), then the stream closed with finish.reason.kind = error instead of a normal message. No answer was produced.

Environment

Item	Value
Surface	DSH Web client (DeepSeek Harness) on a local deployment
Model	deepseek-flash
Provider stream label	DeepSeek Messages stream (Messages-format streaming)
Time (UTC+8)	2026-10-28 20:31:15 → error at 20:31:18
Retries	0 (turn aborted immediately)
Reproduced	1 time so far (single occurrence; no retry yet)

Input (verbatim)

今天行情日K数据已经更新完成了，可以将预约的任务提前执行

Translation: "Today's market daily-candle data has finished updating; you can run the scheduled tasks ahead of time."

Context: this is a message from a human operator to an assistant working inside an internal automation setup. It contains no request for harmful content — it is purely about triggering previously agreed, already-scheduled work now that its data dependency is satisfied.

What the client received

An assistant attempt stream with four items — a reasoning block, then finish:

{"type":"chunk","chunk":{"type":"block-start","index":0,"blockType":"reasoning"}}
{"type":"chunk","chunk":{"type":"reasoning-chunks","index":0,...}}
{"type":"chunk","chunk":{"type":"block-end","index":0,"block":{"type":"reasoning","text":"New user message: \"今天行情日K数据已经更新完成了，可以将预约的任务提前执行\" ... (the model correctly restates the task and plans which pending item to run) — omitted here for brevity"}}}
{"type":"chunk","chunk":{"type":"finish","reason":{"kind":"error","failure":{"message":"DeepSeek Messages stream: unsupported stop reason refusal","code":"MALFORMED_RESPONSE"}}}}

So the reasoning was produced normally; the stream then reported a refusal stop reason instead of a message/finish reason the client recognises.

Why I believe this is a false positive

• No violence, self-harm, illegal activity, sexual content, personal data, or political content in the message.
• It is an operational scheduling instruction, addressed to an assistant that already has an established, approved plan for that work.
• The model's own reasoning shows it read the message correctly and was planning to execute the pending task — the refusal appears to come from a post-hoc safety classification, not from misunderstanding.
• One hypothesis (not a claim): a classifier may be reading "run the scheduled tasks ahead of time" as an agentic/external action and routing it to refusal. If so, that pattern will hit many legitimate automation users.

Questions for maintainers

1. Is stop_reason: "refusal" an expected value of the Messages-style stream? If yes, could the set of possible stop reasons be documented (at minimum refusal, and how clients should treat it)? Right now an unrecognised value turns into MALFORMED_RESPONSE, which looks like a transport bug rather than a content decision.
2. If the refusal is intentional for this input, could you share the general category that triggered it? The text has no obvious sensitive term, and a false positive here blocks a routine automation task.
3. Client guidance: should a refusal stop reason be surfaced as "the model declined" (with no retry), or retried with a modified prompt? A short note in the docs would let client authors stop guessing.

Notes

• The screenshot of the Web UI (处理失败 / 本轮运行失败 / MALFORMED_RESPONSE) will be added in a follow-up comment — GitHub's CLI API cannot upload images.
• Happy to re-test on request, or to provide a longer trace if it reproduces.
• Nothing sensitive is included in this report: no credentials, no session identifiers, no business data.

---

中文摘要：一条完全无害的运营指令（「今天行情日K数据已经更新完成了，可以将预约的任务提前执行」）被上游以 stop_reason: "refusal" 结束流；客户端不认识这个 stop reason，于是报 MALFORMED_RESPONSE（界面显示「本轮运行失败」）。模型其实已经正常产出了 reasoning（说明它读懂了任务），所以更像事后安全分类误判，而非真的越界。想请官方确认：refusal 是否为 Messages 流的合法 stop reason、能否在文档里列出全部取值与客户端处理建议；以及这种"执行已预约任务"的措辞是否会被误伤。

[Muguett-DBY]

I checked the current Harness code at f3803c9. In the DeepSeek Messages adapter, message_delta passes stop_reason to stopReason(). That function currently handles end_turn, stop_sequence, tool_use and max_tokens; every other value goes through malformed(). I also ran that function in isolation: refusal produces the error you saw.

So MALFORMED_RESPONSE here is the Harness client's classification of an unsupported value; by itself it doesn't establish why the provider sent it. For comparison, Anthropic documents refusal as a Messages stop reason, but that documentation is for Claude and doesn't establish DeepSeek's contract or the cause of this particular refusal.

If it happens again, a redacted message_delta event including any stop_details, plus the client/provider versions, could help maintainers distinguish the wire response from the client mapping. Please leave out credentials, private prompts and session identifiers. I haven't made a live DeepSeek request or verified the provider's behavior; the code check was assisted by Codex.

[PedroCostinha]

Hi! One distinction worth making here is between the provider's decision to refuse a request and the client's handling of the response.

Even if the provider incorrectly refused a harmless instruction, a recognized stop_reason: "refusal" should not necessarily be presented to the user as a malformed response.

I would suggest:

1. Preserve the upstream stop reason in the normalized result.
2. If refusal is a documented outcome for this provider, map it to a distinct refusal state instead of MALFORMED_RESPONSE.
3. Show a user-facing explanation without exposing internal reasoning content.
4. Avoid automatically retrying the same refused request indefinitely.
5. Add a regression test with a stream containing a valid reasoning block followed by stop_reason: "refusal".

The potential false-positive classification and the client-side error mapping are two separate problems. The client can improve its reporting even before the provider's refusal behavior is investigated.

Since this happened only once, comparing a second request with the same harmless prompt would also help determine whether the refusal is reproducible.