【在线等】历史加载失败：api gateway: Remote stream WebSocket closed（gateway/internal）

[rengy]

在线等，大家看看还有救么？应该如何处理？

正在对话中，突然就报了下图的错误，无法正常展示历史对话，也看不到当前的输出。

• deepseek-harness 版本：0.1.2-rc.1
• 当前应该是处于提问状态，但看不到提问框
• 一致在这个会话中对话，进行过多轮的 compact，对话记录比较大了
• 升级到 0.1.2-xx 后，有多个会话出现这种情况，之前在 0.1.1-rc2 上是正常的
• 之前通过AI分析过一个对话，说是会话记录中的 seq 不连续

历史加载失败：api gateway: Remote stream WebSocket closed（gateway/internal）

[argszero]

@rengy 这个报错和「AI 分析的 seq 不连续」大概率是两个不同的东西——「Remote stream WebSocket closed」不是 seq/gap 错误，别被 AI 带偏方向。我在 0.1.2-rc.1 的源码上定位了它：

这条报错是「物理连接被关」，不是「日志 seq 有洞」

packages/api/gateway/src/client/stream-client.ts 里，api gateway: Remote stream WebSocket closed 是 lost() 的默认错误（第 236-245 行）：

private lost(
  socket: WebSocket,
  error: RemoteStreamCarrierError = new RemoteStreamCarrierError(
    'api gateway: Remote stream WebSocket closed',
  ),
): void {
  if (this.socket !== socket) return
  this.socket = undefined
  this.failAll(error)      // ← 一击杀掉所有 active Remote stream
}

触发路径：一个已经打开（OPEN）的 persistent WebSocket 收到了 close/error 事件（connect() 里:163-181 的 failed/closed），lost() 就把这个 socket 标注为已失效、并对 this.streams 里每一个 active 逻辑 stream 调 failAll()。所以任何一条远程流的 WebSocket 掉线，历史加载、模型目录、SSE 等所有依赖这个 mux 的逻辑流会同时报「closed」。

关键佐证：真正的 seq 连续性错误，在 packages/api/session-controller/src/history.ts:98 是 另外一个字符串：

throw new RemoteError('gateway/internal', `session log does not contain through seq ${...}`, {})

以及:91-92 的 gateway/bad-request "session page through seq ... is past cursor ..."。从没有源码里会产出「Remote stream WebSocket closed」这一条。所以这是 carrier 掉线故障，不是你的会话记录坏了。

为什么「多轮 compact 后 + 升级 0.1.2-rc.1 后」出现

两个线索其实都指向同一种物理断连而非数据损坏：

1. 版本因素：0.1.2-rc.1 里 Web UI 的历史/状态加载走 /api/remote.mux 这个多路复用 WebSocket。这个 socket 是单例持久的（一个逻辑连接共享给所有 remote stream）。如果会话很长、mux 保持打开很久，中间任何一层（你的反向代理 / 网络 / 浏览器发起的 keep-alive 超时）把 WebSocket 关掉，lost() 就炸掉全部逻辑流。
2. compact 关联：某轮 compact 会改变服务端持有的 cursor / 会话长度，但这不该导致 WebSocket 掉线。更可能纯粹因为会话变长、开着的时间更久，撞上代理/超时的概率更高。「多轮 compact」是个时间 & 会话时长的代理变量，不是因果。

建议你确认的排查方向

• 第一个真正要确认的：Web UI 背后是不是有 nginx / cloudflared / 任意 TCP 层反向代理？如果有，查它的 WebSocket 超时/idle timeout & proxy_read_timeout。这是最容易导致「长时间无消息后 WebSocket 关闭」的地方（和 WebSocket /api/remote.mux fails behind Cloudflare Tunnel (HTTP/2 edge) #5686 Cloudflare Tunnel 那条是同一族）。
• 服务端日志：看是 lost() 触发（socket 关闭），还是 stream-server.ts:189 服务端 Remote stream socket is closed。
• 数据完整性：如果你真的怀疑 seq，请单独用 session-audit 或等价工具做一次日志完整性审计（查 seq-gap / index-reuse）。这是诊断性质的，能明确告诉你日志到底有没有洞——但即使有洞，它产生的也是 gateway/internal 而不是「WebSocket closed」。

我建议的一个加固方向（供参考）

lost() 目前是「一炸全炸」——单个 carrier 掉线把所有 active 逻辑流都标记为失败。可以考虑在 RemoteStreamMuxClient 层面让 lost 走指数退避重连而非直接 failAll，或者至少让 history 这类冷读流在 carrier 掉线后能单独重试，而不是被一起打挂。这比修「seq」更能覆盖你这种「看着看着突然历史加载不了」的场景。

如果你能提供 dsh 服务端的日志片段（尤其是 WebSocket 被谁关闭、第几个帧之后），我可以继续帮你缩小根因。这个更顺手的话，也可以提一个 mux 重连的讨论/参考 diff。

[rengy]

先特别感谢您的分析和答复。另外请问 dsh 服务端的日志存在哪？我一直没找到😭

[rengy]

非常感谢，经反复验证，最终确认是一个网关插件的问题，卸载后可以正常加载会话历史记录。