[BUG] web_search always fails: "DeepSeek returned an unprocessable response body" (brotli not decoded under custom undici dispatcher)

[davis0178]

web_search always fails: "DeepSeek returned an unprocessable response body" (brotli response not decoded when a custom undici dispatcher is installed)

Environment

• Package: @deepseek-ai/dsh 0.1.7-alpha.1 (also reproduced on 0.1.1-rc.2 — the bug predates the 0.1.7 alpha)
• Node.js: v24.15.0, Windows 11 (build 26100)
• Profile: web (default)
• Bug still present on master: packages/web/web-search-deepseek/src/provider.ts still issues a bare fetch() with no accept-encoding handling.

Summary

Every web_search tool call fails with:

DeepSeek returned an unprocessable response body: SyntaxError: Unexpected token 'e', "ePZ..." ... is not valid JSON

The web search request used endpoint "https://api.deepseek.com/anthropic/v1/messages". Search endpoint configuration is separate from chat. ...

The model-facing web_search tool is completely unusable, while web_fetch still works.

Root cause

1. dsh-web-search-deepseek's provider calls bare fetch() with no accept-encoding header, so the client advertises gzip, deflate, br.
2. https://api.deepseek.com/anthropic/v1/messages (served via CloudFront) responds with Content-Encoding: br (brotli).
3. dsh-http-proxy imports userland undici (8.11.0) at boot. undici 8.x mirrors its global dispatcher into the legacy Symbol.for('undici.globalDispatcher.1') slot, so Node's built-in fetch now runs on a custom dispatcher even when no proxy is configured.
4. With that custom dispatcher active, Node's built-in fetch does not decode response content-encoding: the Content-Encoding header comes back as null and the body stays raw brotli bytes (gzip is equally undecoded).
5. The provider's response.json() parses raw brotli bytes → SyntaxError: Unexpected token 'e', .... The 'e' is byte 0x65, the first byte of the brotli stream — hence "ePZ..." in the error.

Evidence (all reproduced locally)

Experiment	Result
curl with Accept-Encoding: gzip, deflate, br to the endpoint	200 OK, Content-Encoding: br, body starts with hex 65 00 10 2D ... (raw brotli)
Node built-in fetch, stock process (no undici loaded)	200, Content-Encoding: br, body correctly decoded to JSON
Same Node script, after require('<dsh>/node_modules/undici') (installs the legacy global dispatcher slot)	200, Content-Encoding: null, body is raw brotli → JSON.parse throws the exact error above
Same, with Accept-Encoding: gzip, deflate	body is raw gzip, still undecoded (not just a brotli-specific gap)
Same, with Accept-Encoding: identity	200, uncompressed JSON, parses fine ✔

Minimal repro (no dsh needed beyond the bundled undici):

require('<dsh-install>/node_modules/undici') // mirrors its global dispatcher into Node's built-in fetch
const r = await fetch('https://api.deepseek.com/anthropic/v1/messages', {
  method: 'POST',
  headers: {
    'x-api-key': KEY, 'authorization': 'Bearer ' + KEY,
    'anthropic-version': '2023-06-01',
    'content-type': 'application/json',
  },
  body: JSON.stringify({ model: 'deepseek-v4-flash', max_tokens: 64,
    messages: [{ role: 'user', content: [{ type: 'text', text: 'hi' }] }] }),
})
const t = await r.text() // raw brotli bytes starting with 0x65 — JSON.parse fails

Verified workaround

Setting 'accept-encoding': 'identity' on the search request makes the server return uncompressed JSON, which parses correctly. (Setting gzip alone does not help — the custom-dispatcher path leaves gzip undecoded too.)

Suggested fixes

1. Immediate: add 'accept-encoding': 'identity' to the fetch headers in packages/web/web-search-deepseek/src/provider.ts.
2. Root cause: do not let importing undici 8.x hijack Node's built-in fetch when no proxy policy is actually active (the dsh-http-proxy "none" path still ends up with undici's default global Agent mirrored into the legacy Symbol.for('undici.globalDispatcher.1') slot), or use undici's own fetch — which decodes brotli correctly — for this request. Note web_fetch works precisely because dsh-web-fetch-http uses undici's own fetch.

---

Filed via GitHub Discussions (issues are disabled on this repo).

[nanami-0713]

Cross-linking #7468 — same root-cause family (bundled userland undici 8 dispatcher installed by dsh-http-proxy → Node's built-in fetch stops decoding content-encoding → raw gzip/brotli bytes hit response.json()), reported from a different symptom surface: there it's the version-update panel receiving undecoded gzip, here it's web_search receiving raw brotli.

Your report adds two data points that matter for scoping, because #7468 is still pinning down exactly when the dispatcher gets installed (its symptom section and its root-cause note disagree on whether proxy env vars are required; see the follow-up discussion there):

1. You reproduce without any proxy configured, which fits your step-3 mechanism (undici 8 mirroring the global dispatcher into the legacy Symbol.for('undici.globalDispatcher.1') slot at import time) better than the env-triggered installProxyFromEnvironment path.
2. You reproduce as far back as 0.1.1-rc.2, so [0.1.7-alpha.1 regression] dsh-http-proxy undici v8 dispatcher breaks content-encoding on internal undici v6 fetch #7468's "0.1.7-alpha.1 regression" framing likely understates the scope — the cross-major pairing (bundled 8.x vs the runtime's built-in undici: internal 6.x on Node 22 there, 7.x on Node 24 here) makes the symptom surface, but the dispatcher installation itself appears to predate 0.1.7.

Both threads converge on the same fix direction: don't override the global dispatcher across undici majors (or build it from the runtime's own undici), plus an explicit accept-encoding/decode guard in consumer code as defense in depth.