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

オープン
#434 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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時間
マージ済み PR(30日)
113

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Tencent/LoopForge のほかの issue

Tencent/LoopForge の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。