PR #346 review 期间代码走读发现的 pre-existing 隐患(三个独立走读均指向同一结论,尚未实际复现):
机制
restoreActiveSessions 的 persistent-backend 探测循环(src/core/session-manager.ts loop2)不跳过 adopt 会话:
- adopt 分支恢复时
forkAdoptWorker 同步设置 ds.initConfig = initMsg,其中 backendType: adoptBackendType(tmux/zellij/herdr,worker-pool.ts ~2775/2800/2830)
- 于是
getSessionPersistentBackendType(ds) 返回持久后端类型,loop2 不会在 !backendType 处跳过
- 循环去探测 botmux 自命名的
bmx-<sid8> pane——adopt 接管的是外部 pane,从来没叫过这个名字 → 恒为 'missing'
- 只要 multiplexer server 在线(
serverState !== 'down'),'missing' 即被判为 solo zombie → closeSession 直接关掉 adopt 会话记录
后果:daemon 重启后(tmux server 存活的常规场景),刚被 forkAdoptWorker 恢复的 adopt 会话疑似立刻被 zombie-close——外部 CLI 还在跑,但飞书桥接断了。loop2 目前只豁免 queued(~line 905)。
建议修法
- loop2 增加 adopt 豁免(
ds.adoptedFrom / ds.session.adoptedFrom),或让 getSessionPersistentBackendType 感知 adopt
- 先写复现测试确认(restore-zombie-close.test.ts 的 harness 可以直接扩:造一个 adopt 会话 + probe 'missing' + server 'running',断言不被 close)
关联
PR #346 review 期间代码走读发现的 pre-existing 隐患(三个独立走读均指向同一结论,尚未实际复现):
机制
restoreActiveSessions的 persistent-backend 探测循环(src/core/session-manager.ts loop2)不跳过 adopt 会话:forkAdoptWorker同步设置ds.initConfig = initMsg,其中backendType: adoptBackendType(tmux/zellij/herdr,worker-pool.ts ~2775/2800/2830)getSessionPersistentBackendType(ds)返回持久后端类型,loop2 不会在!backendType处跳过bmx-<sid8>pane——adopt 接管的是外部 pane,从来没叫过这个名字 → 恒为 'missing'serverState !== 'down'),'missing' 即被判为 solo zombie →closeSession直接关掉 adopt 会话记录后果:daemon 重启后(tmux server 存活的常规场景),刚被
forkAdoptWorker恢复的 adopt 会话疑似立刻被 zombie-close——外部 CLI 还在跑,但飞书桥接断了。loop2 目前只豁免queued(~line 905)。建议修法
ds.adoptedFrom/ds.session.adoptedFrom),或让getSessionPersistentBackendType感知 adopt关联