[Bug][Feature] 0.1.6 默认开启的 dsh_session_log 会让大型会话每次请求携带完整日志（本例 ~260 MiB）导致 TRANSPORT 死循环；建议改为默认关闭 + 首次启动显式征得同意

[yuanBigRun]

TL;DR

0.1.6 起 session-log-deepseek 默认开启，把「尚未接受」的规范会话日志作为 dsh_session_log 字段拼进每一次模型请求（首个上传 afterSeq: -1，携带完整日志）。对一个长期会话，请求体可达几百 MB，更新后每条消息都以 DeepSeek Messages transport failed 结束且永远写不进接受水位，形成死循环。诉求：默认关闭；升级/首次启动时用弹窗明确告知数据内容、去向与用途，由用户主动同意后再开启。

我的诉求

1. session-log-deepseek.enabled 恢复默认关闭（opt-in）。
2. 首次启动/升级后弹窗征求明确同意：说明发送内容（完整会话日志，含工具参数与结果、工作目录路径等）、发送目标（官方端点，或自定义 baseURL 网关）、用途（官方侧诊断/复现），提供「同意」与「暂不」；选择持久化，设置页可随时更改。
3. 未同意前不发送；选择「暂不」后不再反复打扰。
4. 若保留默认开启，至少要有大小上限并保证失败不会让会话不可用（见下）。

Environment

• dsh: master 0d1f50007f（含 dsh-v0.1.6-alpha.1 及之后合并），源码方式运行 Web profile
• macOS（Apple Silicon），Node v26.0.0；provider deepseek-official，model deepseek-flash，protocol messages（0.1.6 新默认）
• 会话：长期任务会话（更新前一切正常），约 12 万事件

症状与时间线

• 16:31 git pull 到最新 master；16:36 起每个 turn 以 DeepSeek Messages transport failed（TRANSPORT）结束；llm/retry 按策略重试 5 次，全部相同失败。同时间段新建会话的小请求完全正常，同一 Key、同一地址的手动请求返回 200。
• 失败样本（日志）：turn 1281–1285 连续 assistant/attempt finish error TRANSPORT。

根因分析

1. packages/session/session-log-deepseek/src/index.ts：请求前取 snapshotEvents(afterSeq + 1) 作为后缀，默认 enabled: true。
2. docs/deepseek-llm-api-wire-extensions.md："The first upload uses afterSeq: -1 and carries the complete current log."、"There is no independent upload store, size cap, or truncation path."
3. 本例日志：120,366 事件、未压缩 260.7 MiB，delivery-accepted 事件为 0 → 每次请求都从 seq 0 全量发送。
4. 巨型 body 在传输层失败；无 2xx → accept() 不执行 → 水位不前进 → 重试和下一条消息继续全量重传。
5. 表面错误仅有兜底 catch 的 DeepSeek Messages transport failed（packages/llm/llm-deepseek/src/protocols/messages/adapter.ts），cause 不落日志，用户无法自行定位（参见 [web] Transport errors hide host error details, making web failures hard to diagnose #543、[Bug] Node >=24 default HTTP/2 fetch corrupts large request bodies against api.deepseek.com: TRANSPORT retry storms (TLS bad record mac + ERR_HTTP2_INVALID_SESSION) #4447）。

Workaround（已验证）

在 profile 的 cordis.patch.yml 中关闭：

- id: session-log-deepseek
  name: '@deepseek-ai/dsh-session-log-deepseek'
  config:
    enabled: false
新建会话可暂时规避，但日志增长后仍会再次触发。
技术侧建议
1. 给字段加上限：未接受后缀超过 N MiB 时跳过且不写水位（或分段 + 检查点上传），避免请求体无界增长。
2. TRANSPORT 错误携带 cause：否则无法区分 TLS、代理与本帖这类字段膨胀问题。
3. 文档与发布说明更醒目：首次上传携带完整日志、无大小上限、自定义 baseURL 网关同样会收到这些数据。
4. 已有同类先例可复用：ui-onboarding 的 welcome notice 机制已经在做"版本化的一次性提示"，同意弹窗可以挂在同一处。

[omnilyra]

升级到v0.1.6-alpha.1遇到楼主相同问题，日志数23465条，约88M;

我觉得是不是至少要守住一条底线，这种数据采集不和主线会话放在一起，走sidecar的模式，至少不要因为这些数据上报影响主线会话。