[Bug] 未分类的空 body HTTP 400 被判为 INVALID_REQUEST，导致长会话被永久锁死

[BigFatWhale-93]

dsh-bug-unclassified-400-INVALID_REQUEST.md

[argszero]

Your report is accurate on every point, and the mechanism is visible in the source — including one design fact you cannot see from the outside that explains why a bodyless 400 lands in the "the request is invalid" bucket, and why that bucket is the wrong one.

The classification, and the evidence it rests on

@deepseek-ai/dsh-llm-pi-ai/src/stream.ts:42-70:

// line 48 — and this one IS justified, by the comment above it:
// "A rejected request body (gateway or provider size cap): resending the
//  same request cannot succeed, so it is invalid, not transient."
if (/\b413\b|failed to buffer the request body:…|payload too large|…/i.test(message)) return 'INVALID_REQUEST'
if (/\b400\b|invalid.?request/i.test(message)) return 'INVALID_REQUEST'   // line 49

Note the asymmetry: the 413 branch above it carries a reason — resending the same request cannot succeed — and the 400 branch carries none. It cannot, because 400 alone is not evidence about the request at all. What your report shows is the precise case where that matters: the message is 400 status code (no body), i.e. the provider returned a status and nothing else, so the harness has no information about whether the request was rejected for its content or whether the gateway blipped. The branch then reads the word "400" out of a terse string and asserts the stronger claim.

That heuristic is not an oversight — the module documents it (stream.ts:34-41):

XXX(pi-ai upstream): pi-ai flattens the caught error to error.message … discarding the original Error and its cause chain before it reaches us. … If pi-ai ever forwards the original Error (or a fetch/dispatcher hook that lets us capture the cause ourselves), classify on code/cause instead of text.

So the text-matching is a documented workaround for an upstream flattening, and your case is its signature failure mode: the one input where there is no text to match on, only a status code. Your (no body) detail is exactly the discriminator — it states the absence of evidence, and the classification proceeds as if evidence were present.

Why the session could not self-heal (three independent gates)

1. packages/llm/llm/src/retry-policy.ts:18-24 — DEFAULT_RETRYABLE_CODES = [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT]; INVALID_REQUEST is not in it, and llm-retry/src/index.ts:215 returns next() (no retry) for any code outside the set.
2. dsh-compaction-basic's overflow recovery gates on CONTEXT_WINDOW_EXCEEDED only, which pi-ai reaches solely through a recognized overflow signal — a 400 with no body produces none.
3. Every new turn re-sends the same, only-growing transcript.

Together those make the failure absorbing: the state that triggers it is the state that persists, and nothing in the path removes it. Your replay evidence (the identical request returning 200 twice afterwards) is what makes this a robustness defect rather than a size limit — and it is the right evidence to have collected.

One thing worth adding to the report: the harness already has the concept you are asking for on the success path. mapStopReason's case 'stop' (stream.ts:96-105) turns a zero-content completion into EMPTY_RESPONSE — retryable — precisely because "the provider returned nothing usable" is a transient condition. The error path never gets that treatment when the text happens to contain 400, so two ways of learning the same fact ("no usable output") end up on opposite sides of the retry gate. Default retry budget is 5 with bounded exponential backoff, so treating your case as transient is cheap: at most five requests per turn, and llm/retry / llm/retry-started events make the attempts visible in the session record.

A workaround you can apply today

retryPolicy is per profile (each pi-ai provider profile owns one), so you can add the code for that gateway alone:

providers:
  opencode-go:                     # the profile in your report
    retryPolicy:
      mode: normal
      retryableCodes: [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT, INVALID_REQUEST]

Two caveats, both real: the list is a replacement, not a merge, so the defaults have to be re-listed or you silently lose them; and it is blunt — it makes every INVALID_REQUEST on that profile retryable, including the genuinely-malformed ones, which then spend five requests before failing. It is a stopgap, not the fix; the fix is to stop asserting "invalid" on evidence the harness does not have.

The plugin form

This is the same over-broad-classification shape as the zero-output case, so it already has a packaged form one code over: @argszero/cordis-plugin-empty-response-retry (https://github.com/argszero/cordis-plugin-empty-response-retry) rewrites a PI_AI_ERROR terminal frame to EMPTY_RESPONSE when the whole attempt produced no visible output, letting the real dsh-llm-retry policy do the bounded retry — the same design as your suggested fix, just applied to a different code. It does not cover your case as published: your frame's code is INVALID_REQUEST, and the predicate is deliberately narrow.

The predicate that would cover it is structural and needs no guesswork: a terminal error frame whose code is INVALID_REQUEST, whose attempt produced zero output, and whose message is a bare status line with no provider-supplied body (the no body marker is what makes it admissible — a 400 carrying a provider error body still names something, and must not be retried blindly). I am extending the plugin along those lines and will report back here with a version to try, so the discussion thread ends with something installable rather than a diagnosis.

Both halves of the upstream ask in your report are correct, and they are separable: the diagnosis half (persist status, headers and a body snippet so a reader can tell a gateway blip from a rejected request) is pure loss today and worth fixing on its own; the classification half is the behaviour change above. Your TL;DR's framing — a transient provider-side failure amplified into a permanent one — is the right way to describe it, and the (no body) string is the reproducer that pins it.

[argszero]

0.2.0 is published and covers your case. Thank you for the reproducer — the (no body) marker is what makes the predicate decidable, and it is now the gate.

npm install @argszero/cordis-plugin-empty-response-retry@0.2.0

What changed

Same seam as before — the public llm/stream waterfall, which sees an attempt and everything it produced — but it now has two recognitions instead of one, and they are the same fact seen twice: a code chosen without a provider-authored diagnosis.

recognition	code	why it is admitted
codes (report #8321)	PI_AI_ERROR	the adapter's catch-all: no rule matched the provider's text at all
statusOnlyCodes (yours, default INVALID_REQUEST)	INVALID_REQUEST	a rule matched, but its only evidence was the HTTP client's own bodyless status line

The second one is gated on the message (statusOnlyMessages), because INVALID_REQUEST is also the correct code for a genuinely malformed request and no plugin can tell the two apart by the code alone. The shipped patterns are:

\b\d{3}\s+status\s+code\s+\(no body\)$     ← the client's own sentence, e.g. "400 status code (no body)"
\b\d{3}\s+(?:\{\}|\[\])$                   ← a body that deserialized to an empty container

Anchored at the end, because when pi-ai writes a provider prefix it comes first (OpenAI API error (400): 400 status code (no body)), and because a real body would have been appended instead. Both fail in the safe direction: any other wording — including a bodyless sentence from a client this plugin has not seen — declines, and declining leaves today's behaviour exactly as it is.

What it produces, for your frame:

// before
{ type: 'finish', reason: { kind: 'error', failure: {
  code: 'INVALID_REQUEST', message: '400 status code (no body)' } } }

// after
{ type: 'finish', reason: { kind: 'error', failure: {
  code: 'EMPTY_RESPONSE', message: '400 status code (no body)' } } }

Only the code changes: the message, status and providerRetryAfterMs are carried through untouched, so the session log still shows what the provider said. The retry itself is still dsh-llm-retry's, on its own unchanged code gate — bounded by that route's maxRetries (default 5) and backoff, and visible as the usual llm/retry events. Nothing was added to DEFAULT_RETRYABLE_CODES; the frame simply arrives carrying a code the default table already admits.

What it does not do — the part of your report it cannot answer

Both halves of your upstream ask are in the report and only one is reachable from a plugin:

• Persist the HTTP status, headers and a body snippet. Not reachable. mapStopReason puts only message and code on the failure, so the status is gone before any listener runs. This half stays a real ask, and it is pure loss today.
• A cheap recovery after repeated identical failures. Compaction is core's, and it keys on CONTEXT_WINDOW_EXCEEDED. Also not reachable from here.
• The classification half is what shipped: an unclassifiable bodyless 4xx is now repeated a bounded number of times instead of ending the turn.

One adjacent case is deliberately not touched: for the single provider whose bodyless 400/413 is already known to mean context overflow (Cerebras, in pi-ai's isContextOverflow), that decision is made upstream of classifyPiAiError, so the failure arrives at the plugin already reported as CONTEXT_WINDOW_EXCEEDED. It is not this plugin's to reclassify.

Evidence

A predicate on text is worth exactly as much as what it is tested against, so the suite derives its fixtures from the installed stack rather than transcribing them:

• the sentence is produced by the installed HTTP clients (APIError.makeMessage in both @anthropic-ai/sdk and openai), and passed through pi-ai's own normalizeProviderError / formatProviderError;
• the resulting code is confirmed by executing the installed adapter's own classifyPiAiError, extracted from the shipped bundle — so the claim "a bodyless 400 arrives as INVALID_REQUEST" is checked against the classifier that makes it, not against a copy;
• the end-to-end arms mount the plugin on a real llm/stream waterfall with a stubbed provider, and the paired control arms run unmounted to show the same turn ending terminal without it, including through the real dsh-llm-retry executor;
• pending and deferred (the adapter's two deliberately non-retryable terminal states) are asserted not to be rewritten, and so is a 400 that carries the provider's own words.

The suite passes on all three lines the peer range admits (0.1.6-alpha.2, 0.1.7-rc.2, 0.2.0-rc.2), and nineteen injected defects — one per decision the guard makes, including both new gates — all turn it red.

Config, if you want to narrow or widen it for your gateway:

plugins:
  empty-response-retry:
    module: '@argszero/cordis-plugin-empty-response-retry'
    config:
      mode: warn                     # log first, don't change behaviour yet
      statusOnlyCodes: [INVALID_REQUEST]
      # statusOnlyMessages: ['\b\d{3}\s+status\s+code\s+\(no body\)$']

mode: warn names the route, the code, the message and which recognition fired, so you can measure your own traffic before letting it change behaviour. Removing the plugin restores the previous behaviour exactly: it is a listener on a documented waterfall, not a patch to the adapter.

The upstream half is unchanged

Your diagnosis is the one that still wants a fix in the tree. The text-matching is documented as a workaround (stream.ts, the XXX(pi-ai upstream) note: pi-ai flattens the caught error to error.message, discarding the cause chain, so classification falls back to text) — and your input is its signature failure mode: the one case where there is no text to match on, only a status code. Classification on code/cause instead of text, and carrying the status and body into the failure, would make this predicate unnecessary; until then it is the best a listener can do, and it is strictly narrower than adding INVALID_REQUEST to a route's retryableCodes, which also retries the genuinely malformed ones.