[Bug follow-up] HTTP 413 from nginx surfaced as INVALID_REQUEST — total request-byte guard and safe session recovery

[iiijiashu]

Observed failure

A long-running session in DSH Desktop displayed:

本轮运行失败
413 Request Entity Too Large
nginx/1.24.0 (Ubuntu)
INVALID_REQUEST

Observed around 2026-10-19 10:51 UTC+08. The response body was nginx HTML; there was no actionable byte-size diagnosis or continuation path.

Verified environment (redacted)

• Windows; Desktop runtime metadata 0.2.1-rc.2.
• An independently installed global npm CLI was still @deepseek-ai/dsh@0.1.5-rc.2 at observation time (we are upgrading it). This is not a confirmed reproduction on the updated CLI.
• A local long-running session recorded 523 events / 1,825,647 bytes uncompressed JSONL (454,322 bytes compressed). Recent model usage contained totalTokens=161995, cacheReadTokens=161536.
• Unverified: the outbound serialized request byte length, the field causing overflow, the reverse proxy's exact body-size cap, whether this provider contributes dsh_session_log, and whether a modern CLI already corrects this specific case. Local session size/token counts must not be confused with HTTP Content-Length.
• No personal identifiers, credentials, private prompt text or full session IDs are included.

Proposed upstream improvement

The dsh_session_log unbounded-suffix problem was already addressed in PR #5168 / 0.1.7-rc.2 (field cap and prefix delivery). This report requests a broader fallback:

1. Final JSON body preflight: measure the full serialized UTF-8 request bytes just before transport. Provide an optional per-provider limit and metadata-only component sizes (messages, tool definitions/results, extension fields, attachments), with secrets/prompt content excluded from diagnostics.
2. Precise error classification: give HTTP 413 (including HTML nginx responses with no structured error) an actionable REQUEST_BODY_TOO_LARGE code rather than a generic INVALID_REQUEST. Preserve ordinary 400 invalid tool schema, 401, 429 and 5xx behavior.
3. Component-directed recovery: cap/defer optional log delivery while maintaining acceptance cursors; compact only the model-visible history when it dominates, using a byte-bounded summarization request; otherwise stop with clear instructions instead of silently resending the same oversized body.
4. Non-destructive continuation: retain complete on-disk history and let users resume without having to reset sessions or configs.

Suggested regression cases

• HTML nginx HTTP 413, no JSON error body.
• A long session with large tool outputs and dsh_session_log disabled, proving total-body sizing works independently.
• A fork/seeded session with missing watermark and the fixed 8 MiB dsh_session_log cap.
• The compaction request itself exceeds the upstream byte limit; error must remain recoverable/actionable without destructive history rewriting.
• Assert serialized request bytes vs limit; no private payload content in logs.

Related prior work

• [Bug] [DSH 0.1.7-alpha.2] 默认开启的会话日志遥测字段把请求体撑到 205.87 MB，并永久锁死会话（可复现，附实测数据） #7699
• Compaction cannot rescue an oversized session — the summarization request itself exceeds the provider request-size limit (HTTP 413) #7626
• 一个请求体字节围栏的参考实现：整包体上限 + 字段级丢弃记账 + 分类器修正 #7820
• [≤0.1.7-rc.1] session-log-deepseek 默认被开启（0.1.6-alpha.1 起）：请求体无上限 → 413 永久自锁，现场报 TRANSPORT 超时（复现 + 实测阈值；rc.2 已修 #5168） #7753

Happy to share a metadata-only, post-serialization byte breakdown with maintainers if there is a recommended debug hook.

[PerryLink]

The classification half is confirmed, and it is deliberate rather than accidental — which changes what the fix should be.

packages/llm/llm-pi-ai/src/stream.ts:48:

if (/\b413\b|failed to buffer the request body:\s*length limit exceeded|payload too large|request body too large/i.test(message)) return 'INVALID_REQUEST'

So any 413, plus the common proxy phrasings, lands on INVALID_REQUEST. And packages/llm/llm/src/retry-policy.ts:18-24 keeps only EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT in the retry allowlist, so INVALID_REQUEST is non-retryable by design — a 413 with an unchanged body would fail identically on retry, so that part is correct behaviour and the "no continuation path" you experienced is the policy working as intended.

Which means the real defects in your report are the two you ranked below the classification:

1. The diagnostic carries nothing. The user sees nginx's HTML and a code. The one number that would make the report actionable — the serialized request size — is never computed. Your proposal to measure the final UTF-8 body before transport is the right shape, and it is cheap compared with what already happens per request (the body is serialized anyway).
2. There is no recovery surface. Non-retryable plus no way to shrink the request means the session is stuck at the same seam forever. This is the same failure shape as #10138, where a gateway preflight 413 cannot be recognised as context pressure and compaction therefore never runs.

On your proposal's component breakdown, one thing I would change: reporting per-component byte sizes (messages, tool definitions, tool results, extension fields, attachments) is the valuable half, and it does not require a per-provider limit. The breakdown also answers a question the classification cannot: whether the offender is dsh_session_log (your #5168 history), tool schemas, or an attachment. A limit without a breakdown tells you "too big"; the breakdown tells you what to cut, which is what the user needs on a permanently stuck session.

Two cautions for the report as filed:

• You marked the CLI version honestly (a global 0.1.5-rc.2 CLI alongside a 0.2.1-rc.2 desktop runtime), and that is the right call. But it does mean the classification path you are describing was verified on this tree, not on the CLI that produced the 413. Worth keeping that distinction visible rather than letting the two versions blur in the summary.
• The INVALID_REQUEST mapping is generic across providers. If the fix is to make 413 more informative, it should not become "413 means context overflow" — a proxy byte cap and a model context window are different bounds, and compaction only helps the second. The useful change is to carry the size, not to reclassify the code.