|
|
bf4fa6e587
|
fix(dsh)★★: 事件数据源字段名错 —— session.events 不存在，真实是 session.log
## 用户报「dsh 插件还是没有正确回复邮件」（第二版）
519bdf7 改了 `lastAssistantText` 的**解析逻辑**（从后往前找带 text 的那条），
生产仍复现。**解析逻辑本来就是对的**，错的是**数据源字段名**。
## 根因（运行时实测，不是推断）
在 idle 回调里打印 agent/session 的实际键表，得到：
session 键：[log, surfaceManager, header, inheritedEventCount,
firstLiveSeq, firstLifecycleSeq, eventsSnapshot,
headerFold, headerFoldSeq, contextFold, contextFoldSeq,
toolHistoryProjection, toolHistorySeq, derived, …]
**没有 `events`。** ⇒ `agent.session?.events ?? []` **永远**兜成空数组
⇒ 每一次都判「空回复」⇒ 给人类发件人发「处理失败」通知。
真正的事件序列是 **`log`**：实测 `Array(26)`、末条 `type=turn/end`、
键 `[type,seq,time,data]` —— 与磁盘 `session.v4.jsonl.zstd` 逐字一致
（磁盘 27 条 / 内存 26 条，差 1 条是 idle 瞬间最后一条尚未写入）。
★ `eventsSnapshot` 名字最像，**实测是 null** —— 照名字写代码会第二次踩坑。
## 顺带修掉第二处同源缺陷
`modelTitle(a?.session?.events ?? [])`（会话标题同步）**也是同一个错字段**，
所以会话标题一直同步不上（静默失败）。
两处曾各写各的、修一处漏一处 ⇒ 收敛为单一函数 `sessionEvents()`，
判据禁止任何地方绕过它。
## 被观测否定的两个推断（都记下来）
1. **「idle 时最后一条事件还没落入内存」** ⇒ 我为此加了 3×250ms 重试
（现已保留，成本极低且无害）。观测 `events=0`（重试 750ms 后**仍为 0**）
直接否定：不是没到，是**压根没有那个字段**。
2. **「根因是 resume 路径」** ⇒ 新会话与 resume 两次都「正常」，因为 dsh
都主动 `send_mail` 而在 `shouldSkipAutoRelay` 早退，压根没走到取文本那段。
## 判据（新增 4 格，含接线层）
纯函数测试抓不到这一类缺陷（`lastAssistantText` 的单元测试全绿）。
新增 `test/session-events-source.test.mjs` 钉住**调用点**：
* 辅助函数必须存在且 **log 排在 events 之前**（判**顺序**不是判存在 ——
`events ?? log` 也含 `.session?.log`，用 `includes` 会免疫）
* 任何读会话事件的地方都必须走 `sessionEvents()`，豁免**按位置**判定
（用 `helperBody.includes(frag)` 豁免会放过代码里**任何位置**的同名字段）
* 回退链保留 `events`（万一是更老的运行时，不比原来更差）
* 自检：合成坏源码必须判红
★ 这份判据自身也踩了两次「对变异免疫」：
`const code = readFileSync()` 模块级缓存、以及上面那个 includes 豁免。
两处都改成**每次现读 / 按位置判定**后才真正有区分力。
**变异验证**：辅助函数改回 events 优先 → 红；把调用点改回直接读字段 → 红。
## 验证状态
dsh 440 格全绿 · tsc 零错 · 部署成功（current → 20261004-080331）· 心跳正常。
⚠ **最终行为验证未完成**：需要一次真人发信（`from_human=true`）才会走到
自动转发那段。我的所有身份都是 Agent，会被「不自动转发」早退。
判空时的 `[diag]` 行已长期保留 —— 下次复现可直接看出是「没有文本」还是「没有事件」。
|
2026-10-04 08:04:10 +08:00 |
|
|
|
519bdf7093
|
fix(dsh)★: 模型写好回信却被当成「空回复」丢弃 —— lastAssistantText 取错那条事件
## 现象（用户实测）
用户看到 dsh 的回复**内容完全正常**（一段完整的「你好 jianf！收到你的问候了 👋…」），
但 AgentMail 里收到的是 dsh 发来的 `处理失败: 打招呼`，正文写着：
这封邮件的处理轮次已结束，但没有产出任何回复文本。
## 根因（从真实会话日志取证，不是推断）
取那次会话的 `session.v4.jsonl.zstd`（zstd 解压 84KB），事件统计：
assistant/message: 2 条 ← 两条！
最后一条 content = [{"type":"tool-call","name":"read_mail",...}] ← 无 text
往前一条 = [{"type":"text","text":"邮件已读取 —— …你好的问候了 👋…"}]
dsh 的一次 step 里，模型先出文本、再发工具调用，会落成**两条**
`assistant/message`；最后那条往往只有 tool-call 块。
而 `lastAssistantText` 是「从后往前找，取到**第一条** assistant/message
就 return —— 不管那条里有没有 text 块」：
if (!Array.isArray(blocks)) return ''; ← 直接判空
return blocks.filter(b => b?.type === 'text')… ← 无条件 return
⇒ 过滤后是空串 ⇒ 判定空回复 ⇒ **静默丢弃模型已经写好的回信**，
改发一封「处理失败」通知给发件人。
## 修法
`return ''` 改 `continue`；只在**真的取到文本**时才 `return`。
## 为什么既有测试全绿
原有 5 格测的**全是单条** `assistant/message`（或只有 reasoning/tool-call 的
单条），与本缺陷正交。新增 2 格用的是**从真实日志取的事件形状**：
* 最后一条只有 tool-call ⇒ 必须往前找到有文本的那条
* **反向对照**：全部无文本时**仍**返回空串，且 `content` 不是数组时应
`continue` 而非当成空回复 —— 保证「空回复」判定没有被放宽成
「几乎总有回复」，否则那封失败通知就没有存在意义了
**变异验证**：把实现还原成原写法 → 21 pass / **2 fail**（正是新增那两格）。
## 影响面
仅 dsh：pi / opencode 走各自宿主的 API 取回复，不共用这个函数
（实测两边的 `lib/` 里没有 `assistant/message` 字面量）。
实测那次只有 34 秒就走到失败通知，是个高频路径而非边缘情况。
dsh 435 格全绿、tsc 零错。
|
2026-10-03 22:24:32 +08:00 |
|
|
|
b4a8f74ae5
|
修复: dsh 邮件通道全断的**两侧**根因（桥侧不产 message id 是真正在写的那一处）
现象：dsh 的邮件通道全断。老会话读不出来 ⇒ 桥报 SessionQueryError ⇒ 按"不在磁盘"
处理 ⇒ 再 create 撞 `already exists`。修好读路径之后又立刻暴露下一层
`message "undefined" is already pending`。
根因一（历史数据，dsh 侧）：v0 会话的 `agent/inbox/spliced.inserted[]` 缺 `id`/`role`，
v0→v1 迁移第一步就拒绝。40 个真 mail-* 会话全部命中。
根因二（**仍在写**，本仓侧）：`plugins/dsh-mail-bridge/lib/message.js` 的
`userMessage()` 只产出 `{content, source}`。DSH 0.1.5 的 inbox 按 `message.id` 去重
（`dsh-agent-loop` 的投影 apply() 与 mutate() 各维护一个 Set），id 全是 undefined
⇒ **第二条消息必挂**。日志里最早的同类记录在 2026-09-07，累计 50+ 次。
官方形状在 `@deepseek-ai/dsh-llm` 的 `createMessage()`（{id, role, content, source}），
同一份 dsh 里其它插件都用官方的 createUserMessage()，只有这个桥手搓。
以前没炸是因为读路径先坏，根本走不到 followup。
本次改动
- message.js/.d.ts: userMessage() 补 id: randomUUID() 与 role:'user'
- test/message.test.mjs: 钉住「id 非空」「两条消息 id 必须不同」，用官方 inbox
去重逻辑逐字复刻验证（修复前 message "undefined" is already pending，修复后 20 封全唯一）
- scripts/: repair-legacy-spliced-ids.mjs（v0，默认 dry-run）、
repair-v3-usermessage-ids.mjs（v3）、verify-mail-sessions-readable.mjs
（走生产真读路径 JsonlSessionPersistence.open，而非解码器口径）、两个 apply driver
- docs/DSH-0.1.5-MAIL-CHANNEL-ROOTCAUSE.md: 补执行结果与两处新事实
执行与验收（详见文档 §9-§15）
- v0 修 40 个、v3 修 2 个；逐文件解压后与备份 `cmp` **逐字节相等**，事件数 40/40 一致，
零丢失（25.2MB→12.5MB 是单帧改 500 行/帧的重压缩，不是丢数据）
- 真 mail-* 会话最终 **41/41 可读**
- journal 里同一会话从 `already exists` 变为 `resume 续谈`，且持续增长
（22647→22685 事件），最新 user/message 带真实 UUID；修复上线后 already pending 计数为 0
- 已在生产部署（deploy/redeploy-plugin.sh dsh，快照+原子软链+重启+后置验证全绿）
两个必须记住的坑
1. **校验与落盘不能共用同一批对象**：createRestore().decodeRow() 会原地改写入参
（补全 dt 数组），污染后写出去会报 `released Session row N has seq gap`。
这曾让 dry-run 说"40 个可修"、apply 只说"3 个"。
2. **判定磁盘健康只认 open()**：readSession() 走 SessionCorpus.load，命中有 live 会话时
直接返回内存快照、不校验磁盘；open() 才走 validateStoredEvents。两条路径结论相反
是设计使然，不是矛盾。
|
2026-09-19 12:03:34 +08:00 |
|
