[Bug] DeepSeek 聊天长历史在启动 CLI 前触发 E2BIG(argument list too long)

未關閉
#434 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
30/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
停滯
技術堆疊
go
領域
backend, cli

研究方向

Start by reviewing PR #429 and the dsh-headless documentation on reading tasks from stdin. Then inspect the existing tests in the internal/httpapi package and trace the three paths named in the issue: first chat, branching, and rebuilding after native-session loss. Done means synthetic inputs over 128 KiB pass through those process-start paths without E2BIG.

由索引模型根據 Issue 內容生成。

描述

组件 / 宿主

Platform — runner / sandbox

现象

一个历史很长的聊天会话(会话体约 170 KB)每次发消息都在模型开始前失败,平台日志形如:

assistant CLI session=...: fork/exec /usr/local/bin/dsh: argument list too long

同一部署里短会话一切正常;出问题的会话反复重试都一样。

初步定位(可能不准,欢迎纠正)

headless dsh 的任务是作为单个位置参数传入的。Linux 对单个 argv 字符串有 MAX_ARG_STRLEN(约 128 KiB)的限制,超过就在 execve 阶段直接 E2BIG,也就是说这不是模型上下文超限,进程根本没起来。

另外两条路径会把整段历史再拼一次、同样中招:分支会话,以及原生会话(--session-id)丢失后按完整历史重建。

按 dsh-headless 的文档,位置参数省略(或传 -)时任务改为从 stdin 读取、且不读 stdin 以外的来源;那把整个任务放进管道应该就能绕开单参数限制。

复现

用合成数据即可:>128 KiB 的历史 + 系统指令,分别走首次聊天、分支、原生会话丢失后重建三条路径。不涉及任何真实会话、日志或凭据。

我做了什么(拙计一版)

我按上面的思路改了一小版并提了 PR #429:

  • DeepSeek 聊天任务改经 headless 的 stdin 通道传输,历史正文不再进 argv;首轮 system 指令同一条管道,续接轮只送增量任务。
  • E2BIG 增加一个固定的脱敏错误码 [ASSISTANT_ARGV_TOO_LARGE],不暴露可执行文件路径或凭据。
  • 回归测试覆盖个人/项目会话的普通聊天、分支、原生会话丢失后的完整历史重建,输入 >128 KiB 且走真实进程启动链路。

我不确定这版是否符合你们执行链的分层约定(SOP 调用路径我没动,只改了聊天),也不确定现在提 PR 是不是时机合适。如果方向不对,或者更希望先讨论方案,请直接说,我立刻关掉 PR,不用顾及情面。

本地能验证的都验了:目标回归测试与整个 internal/httpapi 包通过、go vet ./...、scripts/check-public.py、scripts/scan-secrets.sh 通过;internal/runtime 有 3 个 *GitIndex*Lock* 用例失败,但我在未改动的 main 上也能复现,判断是本机 git 2.43 的锁行为差异,与本改动无关。专用 MySQL/浏览器验收和真实模型测试我没有环境,未运行。

另外两件不打算混进来的事
  • 提示词字节预算与长历史摘要压缩:属于上下文管理,另开 #430 讨论。
  • 本环境的另两类独立错误(一次模型额度不足、一次 MALFORMED_RESPONSE ... tool input is invalid JSON):与本 issue 无关,需要的话我再单独开单描述。
主要語言
Go
星號
141
分支
28
平均合併
1 天 15 小時
30 天內合併 PR
113

環境準備

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

Tencent/LoopForge 的其他 Issue

查看 Tencent/LoopForge 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。