[0.1.7-alpha.1 regression] dsh-http-proxy undici v8 dispatcher breaks content-encoding on internal undici v6 fetch

[pinzza]

Symptom (starting from 0.1.7-alpha.1)

The version-update panel (dsh-version-update@1.4.0) always reports:

registry unreachable (tried https://registry.npmjs.org, https://registry.npmmirror.com):
Unexpected token U+001F ... is not valid JSON

Bytes 1F 8B 08 are a gzip header: the body arrives undecoded despite HTTP 200.
Same failure hits the plugin's GitHub release-notes fetch, so it is host-global,
not registry-specific. curl and a fresh node process (same URL/headers/timeout,
same proxy or direct) both work. Only the dsh web host fails, deterministically,
across restarts, with or without proxy env vars.

Root cause

profile-boot calls installProxyFromEnvironment() from @deepseek-ai/dsh-http-proxy,
which replaces the global dispatcher with one built from bundled npm undici@8.11.0
(Agent factory returning ProxyAgent / Pool). But Node v22.22.2 built-in fetch runs
internal undici 6.24.1. The cross-major dispatcher breaks content-encoding propagation.

Minimal repro (same node binary, internal undici 6.24.1):

const u8 = await import('<global-dsh>/node_modules/undici/index.js'); // 8.11.0
const disp = new u8.Agent({
  factory: (origin, opts) => new u8.ProxyAgent({ ...opts, uri: 'http://127.0.0.1:7890' }),
});
u8.setGlobalDispatcher(disp);
const r = await fetch('https://registry.npmjs.org/%40deepseek-ai%2Fdsh',
  { headers: { accept: 'application/vnd.npm.install-v1+json' } });
console.log(r.headers.get('content-encoding')); // null, header lost
await r.json(); // throws Unexpected token U+001F ... is not valid JSON

With the pristine internal dispatcher (or the same experiment using undici@7.29.0
classes), content-encoding br/gzip is present and r.json() parses. So the
v8-dispatcher + v6-fetch combination is the breaking one.

Environment

• @deepseek-ai/dsh 0.1.7-alpha.1 (global npm install)
• node v22.22.2 (process.versions.undici = 6.24.1)
• bundled node_modules/undici = 8.11.0
• dsh-version-update 1.4.0 (symptom surface only)

Suggested fix

Build the global dispatcher from an undici compatible with the runtime internal one
(or reuse the internal instance), or skip overriding the global dispatcher when the
bundled undici major differs from the runtime. Note: with no proxy configured
(source none) nothing is installed and everything works, confirming the dispatcher
is the trigger.

Workaround

Launch with proxy env fully unset so no dispatcher gets installed:

env -u http_proxy -u https_proxy -u HTTP_PROXY -u HTTPS_PROXY -u all_proxy \
    -u ALL_PROXY -u no_proxy -u NO_PROXY -u npm_config_proxy \
    -u npm_config_https_proxy -u npm_config_http_proxy -u NODE_USE_ENV_PROXY dsh web

Unsetting only http(s)_proxy is NOT enough: any leftover name (e.g. ALL_PROXY)
still triggers installation.

[PerryLink]

Your premises check out on this machine. The part I would narrow is "with or without proxy env vars", because that decides the blast radius.

Verified here. packages/util/http-proxy/package.json depends on undici: ^8.10.0, while the Node running this host is 22.22.3 with internal undici 6.24.1 (process.versions.undici) - the same cross-major pairing you measured, and the same 6.24.1 you reported. The module header states the design intent plainly: "The launcher resolves one policy from the launch environment and installs it as undici's global dispatcher, which is what fetch resolves — so LLM adapters, web search, MCP over HTTP, and telemetry are covered without touching their code" (packages/util/http-proxy/src/index.ts:4-7). apps/cli/src/profile-boot.ts:247 calls it during boot, so the install point is real.

What I would narrow. With no proxy in the resolved policy, nothing is installed at all:

packages/util/http-proxy/src/policy.ts:79   export const DIRECT_POLICY: ProxyPolicy = { noProxy: '', source: 'none' }
packages/util/http-proxy/src/install.ts:176 if (policy.source === 'none') {
:181   if (previousPolicy === undefined) {
:182     active = policy
:183-186  return () => { ... }        // no dispatcher installed, environment untouched

installProxyFromEnvironment resolves the policy and hands it straight to installGlobalProxy (install.ts:296-303). A policy that proxies nothing only installs a dispatcher when one was already installed underneath it (:188-206, the mode: 'off' case); on a plain launch there is nothing to displace, so undici.getGlobalDispatcher() is left as Node's own undici 6 default and there is no version skew available to break content-encoding.

So the first thing worth pinning in the repro is which policy the host resolved, not whether the shell that launched it exports proxy variables. dsh reads a layered environment (loadLayeredEnv('dsh')), so a proxy can be configured for the host without appearing in your shell - and the npmmirror registry in the same report points at a proxied network. Two outcomes, both useful:

• policy proxied → your diagnosis is the whole story, and the blast radius is "every host that resolves a proxy", not everyone;
• policy direct → the v8 dispatcher is not installed, and the gzip symptom has a different cause, which is worth knowing before anyone patches the proxy path.

Boundary: read from the committed tree at c36a83ff6b (dsh-0.1.7-alpha.1). I did not reproduce the version-update panel failure and have not run a proxy-configured host here.

[nanami-0713]

Independent report of the same failure mode, likely the same root-cause component: #7502 — web_search fails with "DeepSeek returned an unprocessable response body" because the provider's response.json() receives raw brotli bytes whenever the bundled undici dispatcher is active, with a full evidence table.

Two data points from there that matter for scoping this issue:

1. It reproduces without proxy env vars configured — attributed there to undici 8 mirroring its global dispatcher into the legacy Symbol.for('undici.globalDispatcher.1') slot at import time, i.e. possibly not just the installProxyFromEnvironment path. That also speaks to the tension inside this report between the symptom section ("with or without proxy env vars") and the root-cause note ("no proxy → nothing installed → works").
2. It reproduces as far back as 0.1.1-rc.2, so the "0.1.7-alpha.1 regression" framing may understate scope: the cross-major pairing (bundled 8.x vs runtime built-in undici) makes the symptom visible, but the dispatcher installation itself appears to predate 0.1.7. (Different runtime majors may also explain differing no-proxy behavior between the two machines: internal 6.24.1 on Node 22 here vs 7.x on Node 24 there.)

Fix suggestions converge across both threads: don't override the global dispatcher across undici majors (or reuse the runtime's own undici), and consider an explicit content-encoding guard in consumer code as defense in depth.

[pinzza]

Correcting my own root cause — with a controlled experiment and fresh-install measurements this time.

First, answering @PerryLink: the reporting host resolved source: 'env' (proxied). http_proxy / https_proxy / HTTP_PROXY / HTTPS_PROXY are all set, so resolveProxyPolicy() takes the proxied branch and a dispatcher is installed. Your reading of the early-return at install.ts:176 is right, though — that is exactly why a source: 'none' host is immune.

But the proxy is not the axis, and 0.1.7-alpha.1 is not the trigger.

Same node v22.22.2 (internal undici 6.24.1), setGlobalDispatcher(...) then built-in fetch, no proxy env at all, direct connection:

bundled undici	dispatcher installed	content-encoding	r.json()
8.10.2	new Agent()	br	parses
8.11.0	new Agent()	absent	throws (body still compressed)
8.11.0	new Agent({ allowH2: false })	br	parses

3/3 runs each. Two consequences:

1. Any userland v8 dispatcher triggers it, proxied or not. The blast radius is "hosts that install a dispatcher", not "hosts that resolve a proxy" — your install.ts reading stands, but the causality is not the proxy.

2. The version that matters is undici 8.11.0, published 2026-09-22T06:57:16Z — 34 minutes after dsh 0.1.7-alpha.1 (06:23:31Z). dsh-http-proxy declares undici: ^8.10.0 in every release up to and including 0.1.7-alpha.2, and that range resolves to 8.11.0 today. Measured on fresh trees today:

   • npm i @deepseek-ai/dsh@0.1.7-alpha.1 → node_modules/undici 8.11.0
   • npm i --package-lock-only @deepseek-ai/dsh@0.1.6-alpha.2 → undici 8.11.0

   So a fresh install of 0.1.6-alpha.2 or 0.1.5-rc.3 today reproduces this too. "Starting from 0.1.7-alpha.1" was a timestamp coincidence, not a version boundary — which also means the "just downgrade" advice floating around for this symptom is wrong.

End-to-end check on the real symptom surface. Running dsh-version-update 1.4.0's own fetchPublished() / fetchReleaseNotes() (unmodified) with the 8.11.0 dispatcher installed:

undici 8.11.0 | direct | internal undici 6.24.1
  fetchPublished    -> FAIL: registry unreachable (tried https://registry.npmjs.org,
                       https://registry.npmmirror.com): Unexpected token '^_',
                       "^_M-oM-?M-=^H^@^@^@^@^@^D^C"... is not valid JSON
  fetchReleaseNotes -> FAIL: Unexpected token '^_', "^_M-oM-?M-=^H..." is not valid JSON

^_ is 0x1F and the replacement glyphs are the 0x8B of the gzip header — byte-for-byte the signature in my original report. Both npmjs and api.github.com fail, which is the "host-global, not registry-specific" observation. The same script against 8.10.2 returns fetchPublished -> OK (25 versions, alpha=0.1.7-alpha.2) and fetchReleaseNotes -> OK (13479 chars).

Upstream cause, now confirmed:

• undici 8.11.0 shipped [Bug] Stream idle watchdog aborts are misreported as `TRANSPORT:terminated`, and provider-level `streamIdleTimeoutMs` never reaches the effective timeout layer #5811 ("preserve HTTP/2 for non-upgrade legacy requests"), which lets HTTP/2 through Dispatcher1Wrapper; the wrapper then passes object-form headers to legacy (v1) callbacks, so Node's built-in fetch loses response headers — content-encoding here, location in the redirect case — while the body stays compressed. Forcing HTTP/1.1 is the control that restores it.
• undici 8.11.0 breaks embedded undici nodejs/undici#5858 — "undici 8.11.0 breaks embedded undici" (302 no longer followed): same root cause.
• Revert "fix: preserve HTTP/2 for legacy fetch consumers" nodejs/undici#5860 — mcollina's revert of [Bug] Stream idle watchdog aborts are misreported as `TRANSPORT:terminated`, and provider-level `streamIdleTimeoutMs` never reaches the effective timeout layer #5811: "allowing HTTP/2 through Dispatcher1Wrapper passes object-form headers to legacy callbacks, causing Node.js global fetch to lose response headers and stop following redirects". Approved by ronag, not merged yet; npm latest is still 8.11.0.

Net ask on the dsh side is one line: pin undici below 8.11.0 (or install the dispatcher with allowH2: false) until #5860 ships. My original framing — "cross-major v8 dispatcher + internal v6 fetch is the breaking combination" — is wrong: 8.10.2 carries the identical cross-major pairing and works fine. Sorry for the mis-attribution; the title of this thread is therefore misleading, so read this comment as the correction.

The workaround in the original post still holds for anyone already on 8.11.0: launch with no proxy env at all, so no dispatcher is installed.

Minimal repro:

import { Agent, setGlobalDispatcher } from 'undici'   // 8.11.0
setGlobalDispatcher(new Agent())                      // new Agent({ allowH2: false }) makes it work
const r = await fetch('https://registry.npmjs.org/@deepseek-ai%2Fdsh',
  { headers: { accept: 'application/vnd.npm.install-v1+json' } })
console.log(r.headers.get('content-encoding'))        // null on 8.11.0, 'br' on 8.10.2
await r.json()                                        // throws on 8.11.0