一个请求体字节围栏的参考实现：整包体上限 + 字段级丢弃记账 + 分类器修正

[txxt114514]

不是新发现。** #6754 提了诉求（"至少要有大小上限，且失败不能让会话不可用"）、#6497 给了咽喉点修法、#6134 给了"跳过失败条目而不是让整个 profile 失败"的主张 —— 到今天还没有一份能跑的代码挂在这里。这篇是代码。不提交 PR（CONTRIBUTING 说明暂不接受外部 PR），只作参考。

上游 dsh-session-log-deepseek@0.1.7-rc.2 已给那个字段加了 maxBytes，自锁解决了。但它约束的是一个字段 —— 引用 @yamingmou 在 #7699 的说法："Same order of magnitude, different object." 下面补的是另外两层。

① 整包体上限

判据是整份 payload 的字节数，不是任何单个字段 —— 所以任何原因变大的请求体都拦得住。

const MAX_REQUEST_BODY_BYTES = 8 * 1024 * 1024;
// fitRequestBody：16 轮阶梯摘录 [[4096,1024]→[96,32]]，仍超限则丢弃该字段

② 丢弃必须记账（#5426 的反对意见是对的：要隔离就明着隔离）

[DSH-REQ] {"status":200,"bodyBytes":1241943,"baseBytes":1229551,
           "droppedFields":["dsh_session_log"],"bodyCeiling":8388608}

③ 分类器：无正文的 400/413 不再一律落 INVALID_REQUEST

原来那个码下游一处都不消费（递归 grep 三种写法：12 处命中全是生产点，0 处分支）。收紧后 dsh-compaction-basic:885、dsh-llm-retry:160 与 DEFAULT_RETRYABLE_CODES 才能正确触发。

⚠️ 反向风险：#2865/#5263 记录的是过度分类 —— 裸 400/413 被判成超限，不可逆地摘要掉 120 条历史（约 72k tokens）。收紧这一层必须同时确认另一侧不会误触发。

实测（一台真机，Windows 11 + openresty 前置）

请求体总计 206,429,335 B
  └ dsh_session_log  205,872,373 B (99.7%)
  └ 消息面              579,474 B
  └ 插件清单              5,916 B
delivery-accepted 事件 0 条（水位从未建立）· 40,833 事件 · 12.0 天

863 条消息 -> baseBytes 579,474 B
208 条消息 -> baseBytes 578,152 B   （差 1,322 B）
  ⇒ 消息数差 4.15 倍，消息面只差 1.3 KB：那 206 MB 与消息数无关

上游请求体上限：8/16/24/32 MB 通过，48 MB 413 ⇒ 落在 (32, 48] MB
修复后：bodyBytes 1,241,943
8 MiB 够吗：本机历史最大被接受的请求体只有 1,451,551 B（1.38 MB），
            闸门触发 1 次。8.39 MB 已是峰值 6 倍 —— 所以我没有提高它。

三条踩坑（这篇最值钱的部分）

1. accept() 的位置不能动。 它必须在 response.ok 分支内、SSE 被消费之前。挪到 2xx 之外就等于让水位撒谎。宁可水位不动。
2. 字段被丢弃时不能写 delivery-accepted —— 推论同上：字段没上传成功，就不存在"被接受"。
3. 不要用总时限给慢请求设卡。 同一位置的历史：DEFAULT_TIMEOUT_MS = 3e4 因误杀大历史加载被投诉（dsh-client-connection：history 等大载荷 RPC 受全局 30s 超时限制，Web 端报「历史加载失败：signal timed out (internal)」—— timeoutPolicy 钩子已存在但无人接线 #7143/dsh-client-connection：history 等大载荷 RPC 受全局 30s 超时限制，Web 端报「历史加载失败：signal timed out (internal)」—— timeoutPolicy 钩子已存在但无人接线 #7144）而去掉，然后 [Bug][0.1.5-rc.2 + 0.1.6-alpha.2] Web 发送链静默挂起：prompt 类 unary RPC 无 deadline，传输挂起时 echo 永不退场（#2060 的翻转面） #7210 报出翻转面（静默挂起）。要做就用"连接空闲"而不是"总耗时"，且必须可配置。
4. 附带一条：别按 catch(() => {}) 的数量去修。 实测 878 个 lib/**/*.js 里 55 处这个写法，只有 1 处属于本族，47 处是正确的串行队列续链守卫（例 dsh-api-terminal-controller:492）。该审计的是成功信号的判据。

局限

8 MiB 是实测峰值 6 倍的经验值，不构成"任何合法请求都能通过"的保证；(32,48] MB 是夹逼区间不是确切值；只测了 deepseek-official 线路；补丁是给 0.1.7-alpha.2 的 dist 写的，上游已改过，不能直接套。

前作：#6754 #6862 #7658 #6497 #6134 #7632 #7310 #7220 #7670 #5426 #2865 #5263

[Ragnoryok1]

Useful data point for ③: a reclassification for exactly this case already exists as a plugin, and I tested it against a recorded failure.

• @argszero/cordis-plugin-length-stop-overflow@0.2.0 (MIT, published) observes the public llm/stream waterfall and rewrites a size-refused finish (INVALID_REQUEST + 413 / size wording) into CONTEXT_WINDOW_EXCEEDED, importing CONTEXT_WINDOW_EXCEEDED_CODE from @deepseek-ai/dsh-llm by value so plugin and core cannot disagree about the code the gate reads.
• I fed it the exact 413 my session recorded: warn → one detection of rule request-too-large, matched by status, with the measured message-JSON bytes; error → the finish comes out as CONTEXT_WINDOW_EXCEEDED; off → no detection. The gate at packages/compaction/compaction-basic/src/index.ts:194 does open once the code is right.
• It deliberately refuses the cases your reverse-risk paragraph worries about: aborted finishes, codes another recovery already owns (CONTEXT_WINDOW_EXCEEDED, IMAGE_OFFLOAD_REQUIRED), size complaints naming an image rather than the request, token bounds, rate limits, malformed requests.

Two boundaries from the other end, which matter for ①:

• The dominant component differs by case. In mine the byte mass was message JSON (126 turns, ~56 MB decompressed corpus, 20,781 events) — the new maxBytes on dsh_session_log would not have touched it. Your "same order of magnitude, different object" cuts both ways.
• A whole-body cap cannot rescue the compaction request the way it rescues a turn: the summarization call replays the shadowed region, so excerpting there silently summarizes less than the log says. In my case the summarization request was itself refused with 413, which is why classification alone cannot recover a session at that size — the cliff is a byte-aware trigger plus chunked summarization (that is Compaction cannot rescue an oversized session — the summarization request itself exceeds the provider request-size limit (HTTP 413) #7626).

Your classifier section and #7626 describe the same gate from two sides; happy to cross-link if that helps.