llm-pi-ai: a gateway's mid-stream interruption wording bypasses retry classification

[apple-ouyang]

Summary

classifyPiAiError in @deepseek-ai/dsh-llm-pi-ai maps an upstream failure
wording to a non-retryable code, so @deepseek-ai/dsh-llm-retry never retries
it.

When a gateway in front of the provider reports a mid-response upstream cut as
plain prose with no HTTP status prefix, the message matches none of the
transport rules and falls through to PI_AI_ERROR:

Upstream response stream was interrupted

Evidence

From DSH session logs (0.1.7-rc.2), failed turns grouped by failure code and
retry events:

code	message	llm/retry events
SERVER	503: {"message":"Service temporarily unavailable",...}	5
SERVER	502: {"message":"Upstream service temporarily unavailable",...}	5
PI_AI_ERROR	Upstream response stream was interrupted	0

The SERVER runs append llm/retry + llm/retry-started before turn/end;
the PI_AI_ERROR runs go straight to turn/end with no retry at all. Both are
mid-response connection losses, so they should classify the same way. The
existing 2026-07-22 note pi-ai-transport-truncation-classification already
sets that principle.

Proposed fix

Classify the wording as TRANSPORT, next to the existing stream-truncation
rules:

if (/upstream (?:response )?stream was interrupted/i.test(message)) return 'TRANSPORT'

PR (on our fork): apple-ouyang#2

The PR also folds in two wordings we currently carry as a local patch against
0.1.7: unexpected EOF (Node's HTTP client for a truncated response body) and
remote error: tls: bad record MAC (Go for a corrupted TLS record).

Note on the retry budget (separate from this fix)

Classification only decides whether a failure is retryable. Normal mode still
defaults to maxRetries: 5 with 500 ms → 10 s backoff (≈15 s total). On
2026-10-03 a local gateway stayed unavailable for ~77 s, so those five retries
were exhausted and the turn still failed. Deployments behind a local gateway can
raise retryPolicy.maxRetries / backoff.maxDelayMs in their provider profile;
we set 8 retries and 1 s → 30 s locally. That is a configuration choice rather
than an upstream default, but it may be worth documenting alongside the retry
executor.

Related

• [llm-pi-ai] Wire finish_reason "network_error" classifies as PI_AI_ERROR and defeats dsh-llm-retry's default retry #4361 — same family: an unrecognized wording fell into PI_AI_ERROR.
• Bug: pi-ai stream_read_error is treated as non-retryable PI_AI_ERROR #3158 (stream_read_error) and [Bug] Node >=24 default HTTP/2 fetch corrupts large request bodies against api.deepseek.com: TRANSPORT retry storms (TLS bad record mac + ERR_HTTP2_INVALID_SESSION) #4447 (DeepSeek H2 upload path bad record mac).