mirror of
https://github.com/badlogic/pi-mono.git
synced 2026-11-05 23:37:25 +00:00
4c992154d9
When a request fails before the provider answers (connection refused or reset, DNS, TLS or certificate, proxy), the `openai` and Anthropic SDKs throw an error with the generic message `"Connection error."`. The actual reason is in the `cause` chain, usually two levels down: undici's `TypeError: fetch failed` wraps `connect ECONNREFUSED 127.0.0.1:8080`. pi built `errorMessage` from `error.message` only, so users, print mode, and session files saw only "Connection error." and had nothing to go on. This change adds `withCauseDetail()` in `utils/error-body.ts`: - It walks the `cause` chain, up to 5 levels, and appends the deepest message, plus its `code` if the message doesn't already contain it. For example: `Connection error.: connect ECONNREFUSED 127.0.0.1:8080`. - `normalizeProviderError` applies it only when the error has no HTTP status and no body. That covers every adapter that goes through `formatProviderError`. - The Anthropic adapter's catch block also uses it, since it read `error.message` directly. Errors without a cause come out unchanged. Retry classification still matches, because the message still contains "Connection error". **Testing** - Added tests to `packages/ai/test/error-body.test.ts`: - a synthetic nested cause chain; - adding the code when the message lacks it; - no cause leaves the message unchanged; - a real `openai` SDK call against a closed local port, which now gives `Connection error.: connect ECONNREFUSED 127.0.0.1:<port>`. - Without the source change, the nested-chain test and the real SDK test fail, because the message is just `Connection error.`. - The full `packages/ai` test suite passes, and `npm run check` passes. Fixes #11695 Requested by @badlogic Co-authored-by: triagent <triagent@localhost> |
||
|---|---|---|
| .. | ||
| agent | ||
| ai | ||
| chord | ||
| codemode | ||
| coding-agent | ||
| durable | ||
| env | ||
| evals | ||
| mcp | ||
| schema | ||
| telemetry | ||
| tui | ||