mirror of
https://github.com/awesome-dsh-plugin/dsh-find-plugin.git
synced 2026-09-28 05:02:55 +08:00
fkysly
fb4d66826a
"Error: fetch failed" is what Node reports for every transport failure, with the actionable part (DNS, refused connection, certificate, TLS) one level down in `cause` — so a report against the plugin carried no way to tell a flaky network from a blocked endpoint. The failure now carries the whole chain, and names the one trap that otherwise reads as a plugin bug: a system proxy or VPN accelerator is invisible to Node's fetch unless DSH itself was started with NODE_USE_ENV_PROXY=1 (or --use-env-proxy). A browser has no such rule, which is exactly why GitHub opens fine while this fails. Verified on Node 25.6: with HTTPS_PROXY set and no opt-in the request goes straight out (200 against a dead proxy at :9); with --use-env-proxy the same request fails against it (ECONNREFUSED). Setting NODE_USE_ENV_PROXY at runtime does not work — undici reads it once when its global dispatcher is created. `DSH_HOME` resolution claimed to mirror @deepseek-ai/dsh-home-paths but skipped its `~` expansion, so `DSH_HOME=~/x` resolved literally and wrote the cache to a `./~` directory inside the working directory. Now expanded the same way the host does it. Tests: 3 new offline cases (28 pass, 2 live skipped); each was mutation-checked — dropping the cause chain, the proxy hint, or the expansion each turns exactly its own case red.