[Bug] Aliyun Bailian / qwen3.6-plus 会在 330s 后固定报 Stream idle timeout

[yongxingcheng81-ux]

问题描述

在 CodePilot 中使用 Aliyun Bailian 的 qwen3.6-plus 进行对话时，如果上游长时间没有返回新的流式 chunk，前端会在 330 秒后固定报错：

Error: Stream idle timeout — no response for 330s. The connection may have dropped.

这个问题看起来不是普通的 provider 连通性失败，而是请求已经发出，但在长时间没有流式事件时被客户端固定空闲超时中断。

环境信息

• 操作系统：macOS
• CodePilot 版本：0.50.2
• Provider：Aliyun Bailian
• Protocol：anthropic
• Base URL：https://coding.dashscope.aliyuncs.com/apps/anthropic
• Model：qwen3.6-plus

复现步骤

1. 在 CodePilot 中配置 Aliyun Bailian provider
2. 选择模型 qwen3.6-plus
3. 发送一个会触发较长思考/较慢首包返回的请求
4. 等待约 330 秒
5. 聊天界面报错：
   Stream idle timeout — no response for 330s. The connection may have dropped.

预期行为

• 如果上游 provider 还在处理请求，客户端不应在 330 秒后固定中断
• 或者至少应提供一个可配置的 stream idle timeout
• 或者在 UI/高级设置里允许对第三方 provider 单独调整该阈值

实际行为

• 330 秒后固定报错并中断当前响应
• 对用户来说像是 provider 挂了，但实际可能只是长时间没有新的 stream/keepalive 事件

补充观察

我检查了当前仓库 main 分支的 src/lib/stream-session-manager.ts，里面仍然有：

const STREAM_IDLE_TIMEOUT_MS = 330_000;

看起来这个阈值目前是写死在前端里的，而不是用户可配置项。

如果这是有意设计，建议：

1. 给第三方 provider 暴露可配置的 stream idle timeout
2. 区分“请求失败”和“长时间无 stream chunk”两类情况
3. 如果 provider 支持 keepalive/heartbeat，确保这类事件能正确刷新 lastEventTime

相关但不完全相同的 issue

• 服务商api无法使用 #257
• [Bug] 服务商 Kimi Coding Plan/GLM (CN) 进程退出报错 - 所有配置正确但 Live 探针超时 #356
• 阿里百炼和直接填写kimi coding 2.5 both not working #412
• KIMI 2.5 CODING plan not working #413
• GLM 5.1 一直卡在 组织回复中 CodePilot v0.49.0 #475

这些 issue 里有 provider 超时、卡住、长时间无响应等现象，但我暂时没有找到和 330s Stream idle timeout 这个固定阈值直接对应的一条。

[op7418]

感谢贴了非常精准的代码定位。你指到的 STREAM_IDLE_TIMEOUT_MS = 330_000 没错，但那只是表面。我查完之后根因和你的几个建议我想展开说一下：

你报告里 lastEventTime 是否被正确刷新的疑问

markActive() 覆盖了 22+ 种 SSE 事件（onText / onThinking / onToolUse / onKeepAlive / onStatus / …），也就是只要上游发任何事件，lastEventTime 就会更新——包括 keep-alive。所以不是"keep-alive 没被采信"的问题。

真正的架构根因

CodePilot 两条 runtime 路径对 keep-alive 的处理是不对称的：

• Native runtime（src/lib/agent-loop.ts:76,119-121）每 15 秒主动发 keep_alive SSE，客户端的 330s 看门狗实际上永远不会触发
• SDK runtime（src/lib/claude-client.ts:1451-1452）只透传 Claude Code SDK 自己发出的 keep_alive——如果 SDK 和上游同时静默，我们没有兜底心跳，客户端真的会在 330s 后 abort

为什么在 v0.50.3 突然开始撞

v0.50.3 把 Agent 引擎的"自动"模式改成了单纯看 CLI 是否安装——装了 Claude Code CLI 就走 SDK runtime。这让 SDK runtime 成为大多数老用户的默认（之前可能因为凭据推断走了 Native）。叠加百炼 Coding Plan 后端对 qwen3.6-plus 这类排队模型首包可能静默几分钟，三者凑齐才撞上这个长期存在的盲点。

修复计划（下个 hotfix）

有两条路，我们倾向两条都做：

1. 根治（优先）：在 SDK runtime 的 SSE pipe 侧也加 15s keep_alive 定时器，对齐 Native runtime 的兜底节奏。这样任何 runtime + 任何 provider 组合都不会再撞这个超时。
2. Provider 级可配置 override：给 provider options_json 加一个 stream_idle_timeout_ms 字段，UI 暴露在"高级选项"里，少数异常慢后端的场景可以单独调阈值。不改默认 330s。

临时绕过（不升级软件）

• 在 CodePilot 「设置 → Agent 内核」里把引擎从 Claude Code 改成 AI SDK——AI SDK 走 Native runtime，有 15s keepalive 兜底，不会撞这个超时。代价：走不到一些 Claude Code 专属能力（斜杠命令 / subagent 等）
• 或者临时改用 Anthropic 官方 / 其他首包快的 provider 做长请求

下个 hotfix 修完会回来通知。

[android-xiaowei]

Error: Stream idle timeout — no response for 330s. The connection may have dropped.

一样遇到这个问题了。我用的是 Claude Code 官方订阅，然后今天一直出现这个问题。

出现这个问题以后，无论再怎么沟通，让它去写文件，它就写不进去了。