fix: 非流式请求（省略 stream 字段）被误判为流式，返回畸形 SSE 响应

[iMissNan]

fix: 非流式请求（省略 stream 字段）被误判为流式，返回畸形 SSE 响应

提交到 https://github.com/techysy/10router/issues/new
标题栏填：fix: 非流式请求（省略 stream 字段）被误判为流式，返回畸形 SSE 响应
正文从下方「### 环境」开始整段粘贴。

---

环境

项	值
10router 版本	1.0.5（npm），同样复现于 1.0.3
部署形态	npm CLI 本地模式，端口 20128
操作系统	Windows 10 (19044)
触发客户端	WorkBuddy（标准 OpenAI SDK 兼容客户端）；curl 亦可稳定复现
相关源码	open-sse/handlers/chatCore.js

问题描述

向 /v1/chat/completions 发送省略 stream 字段的非流式请求时（这是 OpenAI Chat Completions 规范里的默认非流式调用方式，官方 SDK 与多数客户端都这么做），10router 错误地按流式处理，返回：

• content-type: text/event-stream（应为 application/json）
• body 是一个完整的 chat.completion JSON 对象，末尾紧跟一行 data: [DONE]

结果：任何严格 JSON 解析的客户端（OpenAI 官方 SDK、WorkBuddy 等）JSON.parse 直接失败，表现为"测试连接不通过 / 响应解析错误"，导致自定义模型无法接入。

最小复现

启动 1.0.5，配置任意 combo 模型（下文以 my-combo 为例），发送不带 stream 字段、不带 Accept: application/json 的请求：

curl -s http://localhost:20128/v1/chat/completions \
  -H "Authorization: Bearer <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{"model":"my-combo","messages":[{"role":"user","content":"say ok"}],"max_tokens":20}'

实际返回：

HTTP/1.1 200 OK
content-type: text/event-stream        ← 错误

{"id":"chatcmpl-...","object":"chat.completion","model":"my-combo","choices":[...]}data: [DONE]
                                                                                      ↑ 尾部垃圾，JSON.parse 失败

期望返回：

HTTP/1.1 200 OK
content-type: application/json

{"id":"chatcmpl-...","object":"chat.completion","model":"my-combo","choices":[...]}

对照实验： 同样的请求，只要显式加上 "stream": false，返回就是完全合法的纯 JSON（content-type: application/json，无尾巴）。可见问题精确发生在"stream 字段被省略"这一条件上。

根因分析

open-sse/handlers/chatCore.js:114：

let stream = providerRequiresStreaming ? true : (body.stream !== false);

body.stream 省略时值为 undefined，而 undefined !== false === true → 默认走流式。这与 OpenAI Chat Completions 规范相反（规范里 stream 缺省即非流式）。

第 129–136 行确实有一个基于 Accept 头的兜底：

const clientPrefersJson = acceptHeader.includes("application/json");
const clientPrefersSSE  = acceptHeader.includes("text/event-stream");
if (clientPrefersJson && !clientPrefersSSE && body.stream !== true && !providerRequiresStreaming) {
  stream = false;
}

但它只在客户端显式发送 Accept: application/json 时才生效。OpenAI 官方 SDK 与 curl 默认发送的是 Accept: */*（不含 application/json 子串）→ 兜底条件不成立 → 仍然走流式 → 输出畸形 body。

影响面

所有以"省略 stream 字段"方式调用非流式接口的 OpenAI 兼容客户端：OpenAI 官方 SDK 默认行为、WorkBuddy、以及大量第三方集成。这些客户端在 10router 上会全部无法完成非流式对话。

建议修复

把默认语义从「opt-out 流式」改为「opt-in 流式」，与 OpenAI 规范对齐：

// 114 行
let stream = providerRequiresStreaming ? true : (body.stream === true);

第 112 行的 clientRequestedStreaming 已单独处理 ANTIGRAVITY / GEMINI / GEMINI_CLI 等强制流式格式，不受此改动影响；providerRequiresStreaming、图像生成模型（119–121）、deepseek-tui（127）等分支均保留。

我在本地对编译产物（.next-cli-build/server/chunks/8895.js 及 translator 的 send/translate 两个 route）按此逻辑打了补丁（!1!==x.stream → !0===x.stream，共 4 处），实测 WorkBuddy 的非流式与流式两种调用均恢复正常。以上仅为验证根因的临时补丁，正式修复建议由维护者在源码层评估更周全的方案（例如结合 Accept 头默认值或按 sourceFormat 判定）。

附加观察（P2，不影响主结论）

带 tools 参数的流式请求，响应结尾会输出两个 data: [DONE]（正常应为一个）。主流 SDK 读到第一个即停止解析，暂不致命，一并供参考。

---

English TL;DR

Bug: Non-streaming requests to /v1/chat/completions that omit the stream field (the OpenAI spec default, used by the official SDK and most clients) are incorrectly treated as streaming. The server returns content-type: text/event-stream with a body of JSON + "data: [DONE]", which fails strict JSON parsing on the client.

Root cause: open-sse/handlers/chatCore.js:114 — let stream = providerRequiresStreaming ? true : (body.stream !== false);. When stream is omitted, undefined !== false is true, so it defaults to streaming. The Accept-header fallback (lines 129–136) only triggers on an explicit Accept: application/json, but SDKs/curl send Accept: */*.

Suggested fix: default to non-streaming — body.stream === true — while keeping the existing clientRequestedStreaming / providerRequiresStreaming / image-gen / deepseek-tui branches. Verified locally via a patched build; both streaming and non-streaming calls then work.

[techysy]

这是 之前处理 mirasim 的 bug 也有类似问题，那几个报错的解决方案 最后回退了。 我在处理下 新问题

• 11150 — CodeBuddy DeepSeek 模型拒绝 reasoning_effort 参数：

提交 167f272：「Fix: CodeBuddy DeepSeek models reject reasoning_effort auto/off (11150); map auto→high, off→drop」
改动 open-sse/executors/codebuddy-cn.js（+11 行）：auto 映射为 high、off 直接丢弃该参数

• 11133 — CodeBuddy 空工具名导致的报错：

提交 48e39b4：「Fix: normalize codebuddy empty tool_calls function.name in SSE passthrough (fixes unknown tool and 11133)」
改动 open-sse/utils/stream.js（+17 行）：SSE 透传里把 tool_calls.function.name 为空字符串的归一化，避免上游返回 unknown tool / 11133

[techysy]

已修复并合入 main（1cac250a），随 v1.0.8 发布。感谢精准的根因分析——chatCore.js:114 的定位和修复建议完全正确，我们照此落地并做了两点扩展：

修复内容

默认语义从「opt-out 流式」改为「opt-in 流式」，与 OpenAI/Anthropic 规范对齐：

• 省略 stream（含 Accept: */*）→ 非流式 JSON（本 issue 的主症状，官方 SDK / curl / WorkBuddy 均恢复）；
• 显式 stream:true → 流式（不变）；
• 纯 Accept: text/event-stream（不含 application/json）→ 视为显式 SSE opt-in——保护省略 stream 但按头声明要 SSE 的非 SDK 客户端；
• Accept: application/json, text/event-stream 并列（OpenAI/Vercel AI SDK 的非流式签名）→ JSON；
• 您评估过的 clientRequestedStreaming（antigravity/gemini/gemini-cli 强制流式源格式）、providerRequiresStreaming（上游照流、客户端未请求时聚合回 JSON）、imageGen、deepseek-tui 分支全部保留，行为不变。

验证

• 新增 tests/unit/stream-default.test.js 7 例覆盖上述全部组合；
• 全量回归 39 个失败全部在 41 个已知基线内，零新增失败；
• 同类实现对照佐证：CLIProxyAPI 仅显式 stream:true 才流式；OmniRoute 的 resolveStreamFlag 对 openai/claude 源格式同为缺省非流式（他们的 #302/#656/#5305 走过同一条演化路径）。

附加观察（P2 双 [DONE]）

带 tools 的流式响应双 data: [DONE] 这条本次未一并处理（代码里已有 streamDoneSent 去重标记，具体触发路径需要单独复现），如您在 v1.0.8 上仍能复现，欢迎单开 issue 附一份响应尾部原文。

再次感谢——报告里的根因分析直接省掉了我们的定位时间。