[llm-pi-ai] Wire finish_reason "network_error" classifies as PI_AI_ERROR and defeats dsh-llm-retry's default retry

[yangwuan55]

Summary

Some OpenAI-compatible relays terminate a stream with a non-standard wire finish_reason: "network_error" instead of closing the connection. pi-ai's OpenAI-completions adapter already special-cases unknown finish reasons into { stopReason: 'error', errorMessage: 'Provider finish_reason: <reason>' }, so dsh receives the terminal message Provider finish_reason: network_error.

But classifyPiAiError() fails to recognize that text, so the failure falls through to the catch-all PI_AI_ERROR code — which is not in dsh-llm-retry's default normal-mode retryable set. Result: a transient network failure becomes a terminal turn error with zero automatic recovery.

Repro

node -e '
const t = "Provider finish_reason: network_error";
console.log(/\b(?:network|connection|socket|fetch)\b/i.test(t));            // false
console.log(/\b5\d\d\b/.test(t));                                           // false
console.log(/\btime(?:d)?\s*out\b|timeout/i.test(t));                       // false
console.log(/stream ended (?:before|without)\b/i.test(t));                  // false
// every branch misses → classifyPiAiError returns PI_AI_ERROR
'

\bnetwork\b cannot match "network_error" because _ is a \w character: there is no word boundary between k and _, so the trailing \b after network fails.

Failure chain

1. Relay ends the stream with wire finish_reason: "network_error"
2. pi-ai maps it to { stopReason: "error", errorMessage: "Provider finish_reason: network_error" }
3. classifyPiAiError() (packages/llm/llm-pi-ai/src/stream.ts) returns catch-all PI_AI_ERROR
4. dsh-llm-retry normal mode retries only EMPTY_RESPONSE / RATE_LIMIT / SERVER / TIMEOUT / TRANSPORT → delegates without retrying
5. No listener returns { kind: 'retry' } on agent/request-error → LlmError is terminal

Observed live on dsh 0.1.0-rc.8 behind an openai-completions provider: the turn ends with reason.kind === 'error' carrying exactly this message, and no llm/retry events are ever recorded.

Impact

Any flaky relay that surfaces connection problems as wire finish_reason: network_error hard-fails turns with no automatic recovery, even though the failure is transient by nature. Users can work around it per-provider today via:

retryPolicy:
  mode: normal
  retryableCodes: [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT, PI_AI_ERROR]

…but that also whitelists genuinely permanent unknown errors, which is why the default set should classify this correctly at the source.

Suggested fix

Extend the transport family so punctuated variants match (src/stream.ts, classifyPiAiError):

// current
if (/\b(?:network|connection|socket|fetch)\b|\bECONN[A-Z]+\b/i.test(message)

// proposed
if (/\b(?:network|connection|socket|fetch)(?:[\s_-]*error)?\b|\bECONN[A-Z]+\b/i.test(message)

This keeps plain network matching and additionally covers network_error, connection error, etc. I understand the XXX comment above the function prefers cause/code-based classification once pi-ai forwards original errors — this is only the minimal text-level stopgap, consistent with the existing wording list.

Regression test: add 'Provider finish_reason: network_error' to the it.each transport-cases table in packages/llm/llm-pi-ai/tests/convert.spec.ts.