Repository navigation
Open
Labels
area:socialFriends, invites, grants, Bot SocialFriends, invites, grants, Bot SocialbugSomething isn't workingSomething isn't workingneeds-humanThe agent loop stopped; a person must decide (reason in the last comment)The agent loop stopped; a person must decide (reason in the last comment)
Description
现象
每次加载都抛两条未捕获错误,原文:
Error: sessions.retain: unknown session session-e556e8fa-99aa-4dd2-be6d-d383c6cdcb7a
- 两条同 id,
error事件级别,未捕获。 - 该 id 在实例 A 的
state.json里是 A 自己本地 Chief 的 session:mainBotIds[0]、members.owner-1.designatedChiefId、bots[e556e8fa-99aa-4dd2-be6d-d383c6cdcb7a]都指向它。
复现
环境:真 Chromium(/data/uiprobe/browsers/chromium-1248/chrome-linux-arm64/chrome)+ playwright,两户互相独立的实例,隔离数据目录(不使用用户自己的 ~/.dsh):
- A
@selftesta2.home,.dsh-test-a,web 3096 / mock 8796 - B
@selftestb2.home,.dsh-test-b,web 3097 / mock 8797
步骤:
- 用最新 main(
59df1580de392b2157e254e16c900ec98af8450b)启动 A 的实例(DSH_HOME=.dsh-test-a),浏览器打开http://127.0.0.1:3096。 - 在 devtools 里收集未捕获异常 /
error事件并计数。 - 刷新页面一次;再新开一个全新 browser context(无 cookie、无 storage)重开页面。
实际:每次加载稳定 2 条,刷新与全新 context 都复现(A 侧稳定复现;B 侧未逐一采集)。
归属线索
- 抛出点在 DSH 宿主侧的 session controller 客户端,
/opt/flybot/node_modules/@deepseek-ai/dsh-api-session-controller/lib/client.js:3010:
if (typeof target === "string" && !this.sessions.has(id) && !this.summaries.some((summary) => summary.sessionId === id) && address === void 0) throw new Error(`sessions.retain: unknown session ${id}`);同一句也在 lib/types/client/sessions/manager.js:70。
- FlyBot 自己的 client 没有
sessions.retain调用点。main@59df1580, 2026-10-27T02:0xZ 实跑:
$ grep -rn "sessions\.retain" --include="*.js" --include="*.mjs" --include="*.ts" --include="*.json" . | grep -v node_modules | wc -l
0
- 本仓唯一的 retain 调用是 Bot 浏览器的
browsers.retain:
$ grep -n "retain" core/src/client/index.js
276: void browsers.retain(snapshot.bots.map(bot => bot.id))
现状
- 渲染与历史正常,无可见症状:好友列表、会话、消息历史都照常显示,没有空白、没有重试提示、没有丢消息。
- 归属未定:调用
sessions.retain的不是本仓代码,目前只能定位到「DSH 客户端收到一个它自己 catalog 里没有的 session id」,而该 id 在实例状态里确实存在(本地 Chief 的 session)。
已覆盖基线(对照用)
同轮好友列表 8/8 通过,留作将来出现真症状时的对照基线。其中最有价值的两条:
no longer shared行给一句明确解释,不是死界面。原文:Guest2q7gl (@guest2q7gl.selftestb2.home) is no longer shared with you, so messages to it cannot be delivered. It runs on its owner's machine, so another model cannot stand in. Ask its owner for a new invite.- 右键菜单与自己 Bot 行的 Share 入口:好友行 3 项(
Mark as Unread/Bot settings/Copy conversation ID),自己 Bot 行 5 项(Mark as Unread/Edit Bot/Duplicate/Copy invite link/Copy conversation ID),两处都没有 Share 项。
其余覆盖项:连发三条各出现一次且位置递增、刷新后各一次、空输入回车不发送、切换好友不串字、打开好友行 composer 的 aria-label 正确。
上游是否报 DSH:已决——现在不报(2026-10-27T01:09Z,Chief 拍板)。理由两条:①去别人的上游仓库开 issue 必须先经用户点头,用户此刻不在场,不代他点头;②该错误目前零可见症状、归属未定,报上去大概率被当作噪声。处理:#1306 就是我们自己的记录口;等它出现可见症状(渲染/历史异常),或用户主动说「去上游报」,再走一次决策。(本条取代 Triage 评论 6431175125 中「上游是否报 DSH 待用户拍板」的表述。)
Metadata
Metadata
Assignees
Labels
area:socialFriends, invites, grants, Bot SocialFriends, invites, grants, Bot SocialbugSomething isn't workingSomething isn't workingneeds-humanThe agent loop stopped; a person must decide (reason in the last comment)The agent loop stopped; a person must decide (reason in the last comment)
Activity
Birfy commentedon Oct 27, 2026
自测观察到,无可见症状(好友列表/会话/历史均正常),归属未定:抛出点在 DSH 客户端
sessions.retain,本仓无该调用点;上游是否报 DSH 待用户拍板。Birfy commentedon Oct 28, 2026
Written-by: Triage
Park 在本轮:卡在第 1 条判据(要一个设计/归属决定,不是缺信息)。
@deepseek-ai/dsh-api-session-controller的sessions.retain,本仓没有调用点,硬规则也禁止改 DSH。needs-human、摘needs-info(不是"信息不够",是"等人拍板")。另:2026-10-27T01:07:52Z 那条评论没有
Written-by:行;按 #627 登记一次,原文不改。