[Bug] Firefox 特有：会话历史在"载入历史…"处无限卡住

[zhengmz]

[Bug] Firefox 特有：会话历史在"载入历史…"处无限卡住

环境

• dsh 版本：0.1.7-rc.1
• 浏览器：Mozilla Firefox 156.0（Linux，Ubuntu 22.04）
• Chrome：正常（同一 profile、同一会话，Chrome 无此问题）
• dsh web GUI：http://127.0.0.1:3080（用户级 systemd 服务，dsh web --no-open 启动）

症状

在 Firefox 的 Web GUI 中，切换到某个会话时，历史有时会无限卡在"载入历史…"。侧边栏的会话列表能正常加载，只有历史内容区一直不出现。

• 间歇性：有时能加载，有时卡住；刷新页面通常就好了。
• 仅 Firefox：完全相同的会话在 Chrome 里都能正常打开。
• 似乎更常发生在有正在运行的 agent 的会话上；但我也在一个未运行的会话上复现了。

复现步骤

1. dsh web --no-open（或启动该服务）。
2. 用 Firefox 打开 GUI：http://127.0.0.1:3080/?token=…。
3. 点击侧边栏里的某个会话。
4. 观察主内容区一直停留在"载入历史…"。

我用 CUA 复现：启动 Firefox → 打开 GUI → 选中一个会话 → 主内容区 30 秒以上一直停在"载入历史…"。

已验证的事实（对运行中的服务直接做传输/RPC 测试）

这些排除了"服务端/数据/传输"故障：

检查项	结果
ws://host/api/remote.mux 升级（带 Firefox 式 Origin、Sec-Fetch-Site: same-origin、Sec-Fetch-Mode: websocket、Cookie）	✅ 101 Switching Protocols
受影响会话的 session/follow 首帧（快照）	✅ < 50 ms 返回
受影响会话的快照大小	~1.5 MB / 440 事件（最大单事件 121 KB）
受影响会话的运行状态	running: false（未在运行）
Firefox 开发者工具 Network 面板	能看到 remote.mux WebSocket

结论：服务端响应很快、快照很小、会话甚至没在运行。问题出在 Firefox 客户端一侧。

根因分析

"载入历史…"这行文字在会话历史流处于 pending 状态时渲染（dsh-client-ui-chat 中 openState === "loading"）。历史是通过 WebSocket mux 加载的：

session.open() → doOpen() → events.open(HISTORY_PAGE_OPTIONS)
  → RemoteJournalStream.open() → 等待 `session/follow` 流的首帧
  → 由 /api/remote.mux 的 WebSocket mux 承载

有两个根因与现有证据吻合：

根因一：RemoteStreamMuxClient 在 WebSocket 连接失败后不会自动重连（主要怀疑对象）

文件：packages/client/runtime/src/client/stream-client.ts（安装版为 dsh-api-gateway/lib/types/client/stream-client.js）的 maintain()：

maintain() {
    if (!this.running || this.disposed) return;
    if (this.socket?.readyState === WebSocket.OPEN || this.keepAlive !== undefined) return;
    const revision = this.revision;
    const task = this.connect().then(() => undefined, (error) => {
        if (!this.running) return;
        for (const waiter of [...this.waiters]) {
            if (waiter.revision <= revision) waiter.reject(error);
        }
    });
    this.keepAlive = task;
    void task.then(() => { this.keepAlive = undefined; });
}

connect() 失败后，keepAlive 被清空，但没有任何东西再调用 maintain()。唯一的重连触发点是 HTTP 连接层的 onReconnectRequested。所以一旦 WebSocket 失败/断开，而 HTTP RPC 仍健康（这也是为什么会话列表还能加载），之后每一次 session/follow 打开都会在 waitForSocket() 里永远阻塞。

这正好解释了间歇性和仅 Firefox：它取决于 Firefox 的 WebSocket 何时断开（空闲超时、网络闪断，或 Firefox 自身行为），Chrome 不会以同样的方式断开。刷新页面会重新初始化 mux，从而"修复"——与报告的现象一致。

根因二：session.history 分页只按消息数、不按事件数（已知问题）

文件：packages/host/apiproxy/src/api-proxy.ts 的 paginate()。一条流式消息会为每个 chunk 追加一个 assistant/chunk 事件，因此 50 条消息的一页可能解析出数万事件/数 MB。客户端在主线程逐条回放整窗，可能把标签页卡死。这已在 #2119 / #1706 中记录。

建议修复

修复一：mux 自动重连

• 在 maintain() 中，connect() 失败后用退避调度一次重连，而不是只清 keepAlive。
• 在 waitForSocket() 中，若 socket 未就绪且没有进行中的连接尝试，主动触发 maintain()，让新打开的流能"踢"起连接。

修复二：限制历史页大小

• 在 paginate() 中，除了按消息数上限外，再加一个事件数上限（MAX_PAGE_EVENTS，例如 20 000），仍在消息边界切页，保证 loadOlder/hasMore 继续可用。
• 对已落盘、已由 assistant/message 完整重述的旧消息组，裁剪其冗余的 assistant/chunk 事件，只保留最新在播消息组的 chunk 原文。在 Bug: session.history tail page returns unbounded payloads with high reasoning effort (27k events / 5.1 MB → main-thread freeze) #2119 中实测可减少 87–98% 载荷。

相关

• #2119 — Web GUI 卡在 "Loading history…"
• #1706 — Web GUI 无法打开超大会话
• dshdocs：session.history caps pages by messages, not events

[ttbj2023]

根因已在 #5919 定位：hasIntrinsicConstructor（packages/util/values）用精确字符串比较判断原生构造器，假定了 V8 的单行排版。补充 Firefox 实测（151/155，SpiderMonkey）：Function.prototype.toString.call(Object) 输出 "function Object() {\n [native code]\n}"，与 Safari/JSC 同为多行格式，不匹配模板——Firefox 与 Safari 全中，Chromium（V8 单行格式）必然免疫，与本楼“仅 Firefox、Chrome 正常”的观察一致。

间歇性的解释：只有 follow 快照窗口内存在未结算 attempt（原生 chunk 记录含普通对象）时才触发——模型流式输出相位必卡，工具执行间隙/回合结束后正常；“运行中 agent 的会话更常见”正是这个相位相关性的体现（个别未运行会话中招，对应快照里残留的未结算 attempt）。本地在安装包上对该比较做空白归一化后，Firefox 症状消失。