dsh-tui 使用 /v1/responses 时疑似每轮重发完整历史，导致上游频繁报错

[zhexuany]

使用 dsh-tui 连接 OpenAI Codex 兼容服务时，gpt-5.6 系列模型请求持续高频失败，上游典型报错：

• {"error":{"type":"service_unavailable_error","code":"server_is_overloaded","message":"Our servers are currently overloaded. Please try again later."}}
• auth_unavailable: no auth available (providers=codex, ...)（HTTP 503）

服务端观测到 dsh-tui 的请求疑似存在以下行为，想确认是预期设计还是 bug：

1. 每轮对话重发完整会话历史（单次请求体可达数百 KB，未见 previous_response_id 增量续接）；
2. 对 5xx/429 的重试/退避可能不当（未尊重 Retry-After，可能瞬时重试风暴）；
3. 请求中断后可能残留挂起 SSE 流，长期占用上游账号。

走的是 POST /v1/responses。需要更多信息我可以提供。

[denial123789]

从当前 main 的实现说明和源码看，可以先把三个现象拆开：

1. 完整历史：这更像当前架构的预期行为。Agent loop 从持久事件中派生本轮 surface messages；当前生产代码检索不到 previous_response_id 的续接路径（该字段只出现在测试 fixture）。官方的 retry 设计也明确写着：除非恢复策略主动改变 surface，失败后的下一次请求会包含相同的派生上下文。因此数百 KB 请求应先按“无状态完整上下文”而不是异常重复来测量。
2. Retry-After：当前 adapter 会解析并保留有效的 Retry-After，llm-retry 对上限内的 provider delay 应精确采用且不加 jitter；pi-ai adapter 还应把 SDK 自带重试固定为 0，避免双层重试。对应设计说明：
   • https://github.com/deepseek-ai/deepseek-harness/blob/main/.agents/notes/implemented/architecture/2026-06-21-bounded-llm-request-recovery.zh.md
   • https://github.com/deepseek-ai/deepseek-harness/blob/main/.agents/notes/implemented/feature/2026-07-24-provider-retry-policies.zh.md
3. SSE 残留：现有设计声明调用方 abort 和 loop cancellation 为权威边界，但是否泄漏需要线路证据，不能仅从 503 推断。

建议抓一组最小证据再定位具体层：每次线路请求记录时间、Content-Length、provider request id、HTTP 状态、Retry-After、连接关闭时间，以及同一 turn 的 llm/retry 事件。这样可以区分：

• 新一轮确实重发完整历史；
• 同一 provider 请求被 DSH policy 重试；
• 上游兼容服务或 SDK 内部进行了额外重试；
• TUI 已取消但上游连接未收到 abort。

尤其请补充精确的 DSH commit/version、所用 profile 中的 retry mode 和 max delay。若相邻两次请求间隔小于 Retry-After，同时 durable log 里的 llm/retry.delay 又是正确的，问题更可能在 adapter 之外或上游代理层；若 durable event 本身延迟错误，则可以直接收敛到 llm-retry。

更新：我把这套定位方法整理成了完整的四时间线 runbook，包括 wire-attempt ↔ durable-event 对照表、maxRetries: 0 的单层重试边界、取消/SSE 验证步骤和可公开的 incident checklist：

https://sandbaseai.github.io/deepseek-harness-handbook/responses-overload-retry.html