[Bug] Node >=24 default HTTP/2 fetch corrupts large request bodies against api.deepseek.com: TRANSPORT retry storms (TLS bad record mac + ERR_HTTP2_INVALID_SESSION)

[whichoneChen]

[Bug] Node ≥24 default HTTP/2 fetch corrupts large request bodies against api.deepseek.com → TRANSPORT retry storms (TLS bad record mac + ERR_HTTP2_INVALID_SESSION)

TL;DR

On Node ≥ 24 (undici v7 enables HTTP/2 by default in fetch), large request bodies (~75 KB+) sent to https://api.deepseek.com (Tencent EdgeOne) intermittently arrive corrupted: the server rejects the TLS stream with a bad record mac alert, undici destroys the H2 session, and every subsequent retry fails instantly with ERR_HTTP2_INVALID_SESSION because the destroyed session stays in the pool. Users see DeepSeek API request to https://api.deepseek.com failed (TRANSPORT) bursts lasting minutes, then spontaneous recovery. Forcing HTTP/1.1 (Agent({ allowH2: false })) eliminates it completely. This is very likely the same root cause as #978.

Environment

• dsh 0.1.1-rc.2 built from source (master b150a551, 2026-08-21)
• macOS (Apple Silicon), Node v26.7.0 (the [headless] TRANSPORT: DeepSeek API stream fails on the LLM round after a tool call succeeds #978 reporter hit the same pattern on Node v25.9.0)
• Provider: deepseek-official, model deepseek-v4-flash, reasoningEffort: high, maxTokens: 256000
• Web UI, long sessions with tool calls

Symptom

Tasks stream normally for a while, then a turn dies with DeepSeek API request to https://api.deepseek.com failed (code TRANSPORT). Session-log timeline of one burst (captured with a local diagnostic patch that logs the swallowed error cause chain):

10:41:28  finish error TRANSPORT   ← first failure
10:41:28  finish error TRANSPORT   ← retry 1, ~500 ms later
10:41:29  finish error TRANSPORT   ← retry 2
10:41:31  finish error TRANSPORT   ← retry 3
10:41:35  finish error TRANSPORT   ← retry 4
10:41:43  finish error TRANSPORT   ← retry 5, turn ends in error

Failure windows last minutes (bursts at 09:53 / 09:54 / 10:00 / 10:09 / 10:10 all failed; 10:21 recovered), then heal spontaneously. Note the sub-15 ms failures on retries — too fast for a network round trip.

Client-side network was ruled out: during a failing window, a plain curl POST to the same endpoint from the same machine returns HTTP 401 (reachable, auth-only). DNS, system proxy, VPN, IPv4/IPv6 all verified stable.

Root cause (error chains captured)

The shipped LlmError only carries the top-level message; the session log never shows the cause. Patching packages/llm/llm-deepseek/src/adapter.ts to log error.cause before throwing reveals two distinct layers:

First failure — TLS record corruption on the H2 upload:

TypeError: fetch failed
  cause: Error: ssl3_read_bytes:ssl/tls alert bad record mac (SSL alert number 20)
         code=ERR_SSL_SSL/TLS_ALERT_BAD_RECORD_MAC, http2ErrorCode: 2

The server detects the corruption (alert received client-side), i.e. the client's TLS records were already damaged on the wire — with TCP checksums passing, this points at the HTTP/2 write path in the client stack (bundled undici v7 H2 + OpenSSL), not the network.

All 5 retries — poisoned H2 session pool:

TypeError: fetch failed
  cause: Error: The session has been destroyed (code=ERR_HTTP2_INVALID_SESSION)

Each retry reuses the destroyed session and fails instantly without any connection attempt. The multi-minute "outage windows" are just the pool holding the dead session until cleanup, and users re-triggering bursts with manual retries.

Minimal reproduction (no dsh needed)

Node v26.7.0, macOS. Intermittent but frequent; run the H2 case a few times.

const body = JSON.stringify({ messages: [{ role: 'user', content: 'x'.repeat(75000) }] })

// 1) Default global fetch — negotiates HTTP/2 via ALPN → intermittently:
try {
  await fetch('https://api.deepseek.com/chat/completions', {
    method: 'POST', headers: { 'Content-Type': 'application/json' }, body,
  })
} catch (e) { console.log(e.cause) }
// Error: ssl3_read_bytes:ssl/tls alert bad record mac
// code=ERR_SSL_SSL/TLS_ALERT_BAD_RECORD_MAC http2ErrorCode: 2

// 2) Forced HTTP/1.1 — same payload, same machine, succeeds every time (401 = auth-only):
import { Agent, fetch as undiciFetch } from 'undici'
const http11 = new Agent({ allowH2: false })
await undiciFetch('https://api.deepseek.com/chat/completions', {
  method: 'POST', headers: { 'Content-Type': 'application/json' }, body, dispatcher: http11,
})
// → 401

Workaround / suggested fix

An explicit HTTP/1.1 dispatcher in the DeepSeek adapter fixes it end-to-end (verified on a long-running session that previously failed every few minutes):

--- a/packages/llm/llm-deepseek/src/adapter.ts
+++ b/packages/llm/llm-deepseek/src/adapter.ts
+import { Agent, fetch as undiciFetch } from 'undici'
+
+const deepseekHttp11Agent = new Agent({ allowH2: false })

-        response = await fetch(`${connection.baseURL}/chat/completions`, {
+        response = await undiciFetch(`${connection.baseURL}/chat/completions`, {
           method: 'POST',
           headers,
           body: payload,
           signal,
+          dispatcher: deepseekHttp11Agent,
         })

Beyond the workaround, two upstream-worthy angles:

1. Even when the first failure is a genuine network hiccup, the retry storm turning it into a multi-minute outage is an undici H2 session-pool behavior — the adapter/retry layer could detect ERR_HTTP2_INVALID_SESSION and force a fresh connection instead of replaying against a destroyed session.
2. This also relates to the existing TODO(http): adopt the Cordis HTTP service in the adapter — shared transport configuration (including explicit protocol/dispatcher policy) would give users a knob for this class of problems.

Happy to turn the diagnostic patch (logging swallowed transport causes) into a PR if useful — it made this whole investigation a 5-minute exercise instead of a guessing game.

Related

• [headless] TRANSPORT: DeepSeek API stream fails on the LLM round after a tool call succeeds #978 — same model (deepseek-v4-flash), same "LLM round after a tool call fails with TRANSPORT, retries all fail, cause invisible in session log" pattern; headless vs web only changes how often it surfaces.
• [web] Transport errors hide host error details, making web failures hard to diagnose #543 — transport errors hiding host error details.

[whichoneChen]

#4448 is a sibling root cause worth reading together

#4448 (intranet proxy environment: Node fetch ignores HTTP_PROXY, direct connection hits the corporate firewall with ECONNRESET) and this report (direct connection: Node >= 24 defaults to HTTP/2, large request bodies intermittently corrupt at the TLS layer → bad record mac → destroyed H2 session stays pooled → ERR_HTTP2_INVALID_SESSION retry storm) surface the exact same user-facing error — DeepSeek API request to https://api.deepseek.com failed (TRANSPORT).

Two observations for whoever picks these up:

1. The two proposed fixes are complementary and non-overlapping. installEnvProxy() from dsh web 在内网代理环境下请求 DeepSeek API 失败 — 现象 / 原因 / 修复方案 #4448 is a no-op when no proxy env vars are set, so it would not prevent the H2 upload corruption reported here; conversely, the Agent({ allowH2: false }) dispatcher in this report does nothing for proxy-restricted intranets.
2. Both trace back to the same architectural gap already flagged by the TODO(http): adopt the Cordis HTTP service comment in adapter.ts: plain fetch() with no explicit transport configuration. A single configurable transport seam — proxy support + protocol policy + retry resilience against ERR_HTTP2_INVALID_SESSION (a retry that replays against a destroyed pooled session can never succeed; the retry layer could detect this and force a fresh connection) — would close out the whole family of opaque TRANSPORT failures.

Also worth noting: both reports only became diagnosable after patching the adapter to log the swallowed error.cause chain. The shipped LlmError message hides the actionable detail in every one of these cases.