[bug] 打开会话时，如果AI正在回复，会长时间卡在 载入历史 状态

[vesita]

原因我让AI帮我查的，正常打开一个大会话也不会卡，就是AI回复时，会话会阻塞
症状：多个会话并行时，进入一个 agent 正在回复的会话会长时间显示「正在切换历史」
关键数字：1% 的数据付 100% 的解析成本；32 ms/千事件；解码期事件循环独占 0.5 s；memo 仅 2 条
相关位置：dsh-session-persistence-jsonl/lib/index.js:2176/2183/2638、dsh-session-query/lib/index.js:410、dsh-api-session-controller/lib/index.js:1489

[vesita]

版本号: 0.1.6-alpha.2

[lym5210]

有什么办法解决吗

[vesita]

有缓解方案，但是我没弄，也是AI做的，但是我现在不方便贴给你，可能要晚点

[vesita]

补丁验证完成——探到了下限：

yield 间隔	open+read 总时长	事件循环最大独占
500（原版）	703.5 ms	693.1 ms
50	688.8 ms	211.3 ms
10	696.2 ms	170.6 ms
0	731.2 ms	169.3 ms

结论很清楚：

• 原版几乎是整段 0.7 秒独占事件循环（探针整整 0.7 秒只跑了 2 次 tick）——这就是「AI 一回复，会话就进不去」的直接原因：host 主线程被日志解码锁住，agent 的流式输出和你的切换请求一起排队。
• 改成 10 ms，独占时长降到 171 ms（4 倍改善），总时长反而没变（696 ms，yield 开销可忽略）。
• 171 ms 是下限：它来自「单个超大帧不可中断的解码」（源码注释原话 One frame remains an indivisible synchronous decode）。再往下压必须改帧粒度，那是动 dsh 的解码结构，我不建议。

yield = 0 反而更差（总时长涨到 731 ms，独占没再降），所以最优值是 10。

你要执行的命令（一条）

F=/usr/lib/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-session-persistence-jsonl/lib/index.js
sudo sed -i 's/const ZSTD_DECODE_YIELD_INTERVAL_MS = 500;/const ZSTD_DECODE_YIELD_INTERVAL_MS = 10;/' "$F"
grep -n "ZSTD_DECODE_YIELD_INTERVAL_MS = " "$F"

最后那行应该输出 :2183:const ZSTD_DECODE_YIELD_INTERVAL_MS = 10;，然后重启 dsh 生效。

两点必须说清楚

1. 这是缓解，不是根治。 它解决的是「AI 回复与会话进入互相卡死」的那个耦合点（683 → 171 ms）。但 cold open 本身仍是 ~0.7 秒，前端渲染（firefox 那次采样 34% 单核）我也没动。体感上应该从「明显卡住」变成「轻微顿一下」。

2. COLD_LOG_MEMO_MAX_ENTRIES（2 条）我先不建议动。 把它调大能直接免掉 cold open（命中缓存只要 1.5 ms），但 memo 存的是解码后的完整事件数组——你那个会话 zstd 21.8 MB、解压 80.9 MB，多缓存两份就是几百 MB。你的 dsh 现在 RSS 已经 779 MB，我不想拿 OOM 风险换速度。如果 10 ms 这个补丁后你还是觉得不够，我们再单独评估这一项。

另外提醒两件事：

• 你的 ~/.dsh/profiles/web/cordis.patch.yml 已还原（disabled: true 那两行已移除）。如果你的 dsh 还没重启，collab 可能仍停在禁用态，重启一次就恢复。
• 保险起见：这次改的是系统包，pacman 升级会覆盖掉。

要我把这个 sed 固化进 PKGBUILD 的 prepare() 吗？这样以后每次 makepkg 重建包都自动带上这个补丁，升级也不用重新记这一步。

这是之前AI的给出的解决方案，我没有尝试过，但就是这个AI这次会话中发现的这个问题