[Bug] 请求准备阶段缺附件被包装成 TRANSPORT 并重试 5 次后本轮失败 / missing attachment store surfaces as TRANSPORT

[RACErace]

环境

项	值
系统	Windows 11
Node	v24.15.0
DSH	0.1.6-alpha.1（npm alpha）；同机另有 0.1.5-rc.2 实例作对照
Provider / Model	deepseek-official / deepseek-flash，reasoningEffort max
协议 / baseURL	Messages（0.1.6 默认）/ https://api.deepseek.com/anthropic
网络	直连；系统代理未注入 Node（HTTP_PROXY/HTTPS_PROXY 未设置、未设 NODE_USE_ENV_PROXY）

现象

同一会话连续 7 轮（turn 134–140，约 18 分钟）全部失败：

• 界面：已重试模型请求（5/5） · 9s，展开只有两行 —— 重试延迟：8124 毫秒、失败原因：DeepSeek Messages transport failed；随后 本轮运行失败 TRANSPORT。
• 会话事件：每轮 1 次首试 + 5 次重试全部失败；每次 assistant/attempt 只含一个 finish/error 合成 chunk（零内容块、零 usage、无 HTTP status），attempt 自开始到失败约 6–42 ms。
• 该会话同时含 dsh-memory 插件的上下文注入行（与本问题无关，只是同时出现）。

真实原因

该实例的 DSH_HOME（独立数据目录）里没有 attachments/ 附件库，而会话上下文里有 33 个未 offload 的 image 块（32 个唯一 sha256 附件 id）。Messages 路径在 prepareImages() 里逐个 attachments.readImageRequest() 读图字节时失败（AttachmentError: ATTACHMENT_NOT_FOUND，不是 LlmError），被适配器兜底 catch 统一包装成 DeepSeek Messages transport failed / TRANSPORT，随后按默认策略重试 5 次并终止本轮。

证据：

• 32/32 个附件 id 在原数据根的 attachments/v1/objects/<前2位>/<id> 全部存在——图没丢，只是这个数据根里没有附件库；
• 该 33 个 image 块中 offloaded: true 计数为 0、会话里 image/offload 事件计数为 0 → 请求确实需要读这些字节；
• 同一会话文件、同样的图片上下文，稳定版（0.1.5-rc.2）TRANSPORT = 0；
• 网络侧实测全部正常：直连 POST https://api.deepseek.com/anthropic/v1/messages（假 key）返回 401；body 0.05 / 1 / 10 MiB 分别 150–250 / 193 / 281–488 ms；同一连接池连发 12 次 1 MiB POST 全部 401（68–297 ms）；ALPN 探测服务端 h2 与 http/1.1 均可用。失败耗时（6–42 ms）比任何一种成功往返都短，说明请求根本没走到网络。

触发条件：把历史会话复制/迁移到另一个数据根，且请求准备阶段需要读图。纯文本会话不会出现；图片恰好全部被 offload 时也不会出现。

已排除

• 0.1.6 新增的 image/offload 会话事件不是原因：该会话 image/offload 事件 = 0、offloaded: true = 0，33 个 image 块都还在上下文里；且适配器是先读图（prepareImages）再做预算判断（requiredImageOffload → IMAGE_OFFLOAD_REQUIRED），本次失败发生在读取阶段，走不到 budget 判断。offload 若触发反而会让请求不再读这些字节，从而掩盖此问题。
• 网络抖动 / HTTP/2 死连接（正常请求 68–488 ms，重试全程 6–42 ms）；
• session-log-deepseek 巨型请求体（失败发生在请求发出前）；
• 附件服务缺失（那会抛 UNSUPPORTED_CONTENT，实际错误码是 TRANSPORT）。

规避

把完整用户数据目录复制到新数据根（至少 attachments/，另可带 llm-deepseek/ 这个附件→provider file-id 缓存）。我们据此给本地启动器的数据复制清单补上这两个目录后，同一会话即恢复正常。

期望上游改进

1. 保留 cause / 失败分类：llm-deepseek 的兜底 catch（packages/llm/llm-deepseek/src/protocols/messages/adapter.ts:79，以及 chat-completions 分支的对应处）把请求准备阶段的任何非 LlmError 都写成 TRANSPORT 并丢弃 cause。建议至少把 cause.code/message 落到界面细节、会话事件或 ctx.logger.warn（例如 ATTACHMENT_NOT_FOUND: sha256:…）。否则用户会去查网络、查代理、查这次发布的新特性——本次排查就是这样被带偏的。
2. 准备阶段的失败不应按传输错误重试：附件缺失 / 本地 I/O 类失败重试 5 次不可能成功，只是把首次报错延后约 9–15 秒。建议这类失败直接终止本轮，或换一个不可重试的错误码。
3. 缺失附件时给可执行提示：例如"请求需要附件 sha256:xxxx，但当前 DSH_HOME 的附件库中不存在；请检查是否更换过数据目录 / 迁移数据时漏了 attachments/"。
4. （可选）会话里即使没有 image/offload 事件，也能看到"本轮读取了哪些附件"的轻量记录，便于用户自助定位。

关联

可能相关的既有讨论：#6754（同错误串，session-log-deepseek 巨型请求体）、#6401、#4447、#543（传输错误隐藏宿主错误细节）。

[RACErace]

补充：本次还定位到第二条独立触发路径（与附件缺失去无关，同样表现为"本轮运行失败"）。

现象

同一实例、换了一个会话，连续多轮失败，但这次错误码不是 TRANSPORT：

本轮运行失败  DeepSeek Messages cannot represent user/tool-result content reasoning   UNSUPPORTED_CONTENT

（UNSUPPORTED_CONTENT 不在默认 retryableCodes 里，所以没有 5 次重试，直接终止本轮。）

原因

Messages 序列化器对 user / tool-result 消息只允许 text / image 两种内容块（packages/llm/llm-deepseek 的 Messages 序列化器：input() 的 unsupported('user/tool-result content ' + block.type)）。而历史会话里存在这样一条消息（本机实测样本，来自子代理结束通知，source.kind = "subagent-settled"）：

{"type":"user/message","seq":10998,"data":{"role":"user",
 "source":{"kind":"subagent-settled","form":"notice","senderSessionId":"…"},
 "content":[
   {"type":"text","text":"Background subagent … finished and will do no further work unless you send it more."},
   {"type":"text","text":"Its closing message:"},
   {"type":"reasoning","text":"Now let me write my final report …"},
   {"type":"text","text":"…"}]}}

role = user，但内容数组里带了一个 reasoning 块。只要该会话在 0.1.6 上继续，每一轮都会在序列化阶段硬失败，且用户看到的只有一句话，看不出是哪个块、哪条消息。

为什么现在才炸（对照）

provider 适配器	user / tool-result 里出现未知块
chat-completions（0.1.5-rc.2 及更早）	case 未命中走 default: break → 静默丢弃
Messages（0.1.6 默认）	unsupported() → 抛 UNSUPPORTED_CONTENT

也就是说：这类"畸形"历史数据一直存在（本机两个数据根里共 31 个会话、105 条同类消息，最早可追溯到 9-11），只是旧链路宽容、新链路严格才暴露出来。

上游侧的一点情况

0.1.6-alpha.1 里的 dsh-subagent 已经加了写入端防护（createSettlementMessage 只把 type === 'text' 的块放进通知，源码注释也写明"Parent providers receive this notice as a user message and may reject nontext assistant blocks"）——新写入不会再有。但：

1. 磁盘上的历史脏数据仍然存在，读取/序列化端没有做兼容；
2. 上游修的是"写入"，不是"读取宽容度"。

建议

在 Messages 序列化器（以及 chat-completions 侧保持一致）对 user / tool-result 内容采用与旧行为一致的降级策略：遇到未知块时跳过该块（并可选记一条 warn），而不是让整轮失败；至少把错误信息补上足够的定位信息（消息 seq / 块类型 / 块索引），现在这句 cannot represent user/tool-result content reasoning 无法让用户找到是哪条历史消息。

（本地已按此思路清理了 31 个会话的 105 条历史脏消息，两个数据根各留了一份
.bak-<时间戳> 备份；这是数据侧规避，不是修复。）

[RACErace]

追加：同一会话的第四个失败面 —— 413 Request Entity Too Large

前三层（缺附件 → TRANSPORT、历史脏 reasoning 块 → UNSUPPORTED_CONTENT）修掉后，同一会话继续跑，出现：

本轮运行失败  DeepSeek Messages request failed (413)   INVALID_REQUEST

实测的网关限制（本机，两个端点都测）

用无效 apiKey 发 POST，观察状态码（401 = 请求体被接受、只挑鉴权；413 = 因体积被拒）：

body 大小	/chat/completions	/anthropic/v1/messages
2 / 6 / 12 / 24 / 40 MiB	401	401
64 / 96 MiB	413	413

413 的响应体是 nginx 的 <h1>413 Request Entity Too Large</h1>，属网关层限制，与协议、鉴权、apiKey 均无关。所以切协议不能绕过（我一开始猜是端点差异，实测推翻；特此更正）。

为什么会到这个量级

同一会话（12,554 事件）的当前模型上下文估算：

• 未被 prune 的事件 ≈ 39.3 M 字符，其中 assistant/message 占 38.5 M
• 会话里的 32 张图片字节只有 6.3 MB（base64 后 8.4 MB）——图片不是主因，文本历史才是
• 会话有 5 次 compaction，但 compaction/prune 只标记了 44 个 seq（12,511 个事件里）→ 压缩基本没起作用
• 同机另一实例（0.1.5-rc.2，chat-completions）在上下文较小时段能正常完成请求，说明链路本身没问题

期望

1. 压缩策略要真的能压：这个会话 5 次 compaction 只 prune 了 44/12,511 个事件，长会话因此能一路膨胀到网关上限；建议 compaction 以"渲染后字节/token 预算"为触发与终止条件，而不是仅按事件数。
2. 配额/上限要前置暴露：适配器（或 agent loop）无法从 provider 配置得知网关的请求体上限；如果有一个"渲染后字节上限"的软阈值（例如命中就强制 prune/报 CONTEXT_WINDOW_EXCEEDED 类可读错误），就不会以 413 的形式在传输层炸掉。
3. 错误可读性：413 被包装成 DeepSeek Messages request failed (413)，用户看不出是"请求体过大、需要压缩/新开会话"，也不知道阈值在哪。

（本地缓解方式是人工折叠/重建该会话上下文；不改网关行为。）