fix(sse): skip model-only lockout for an isolated 5xx after the stream relayed output

[QuangBlue]

Problem

A streamed response that has already sent text, reasoning or a tool call to the client can still fail upstream: for example Internal error during token generation 45–80 s into the answer, or a stream active timeout / terminated pipeline error. That failure goes onStreamFailure → markAccountUnavailable, and for a per-model-scoped connection (passthroughModels) it records a model-only lockout.

The client response is already committed, so the lock cannot help that request. It only takes the model away from every other client, and on a single-account provider it removes the model entirely until the lock expires.

In our deployment, over 8 days almost all 5xx model-only lockouts on one single-account provider were of this kind: 27 of 31 came after the stream had already relayed content. Hundreds of concurrent streams on the same model succeeded during the same period. Of the remaining 4, 3 were caught by the combo quality peek before any content, and 1 was a non-stream HTML 520.

Fix

• streamTiming.ts: each SSE transform's StreamTiming is registered in a WeakMap. A new streamEmittedOutput(stream) reads the existing firstOutputAt marker (the first forwarded chunk carrying text, reasoning or a tool call).
• streamFailureFinalization.ts and chatCore.ts: stream failures now carry outputEmitted, read at failure time. This covers pipeline errors (terminated, stream active timeout) as well as in-stream upstream errors.
• chatHelpers.ts and auth.ts: onStreamFailure passes streamOutputEmitted to markAccountUnavailable.
  • The per-model branch now treats a post-output 5xx like the existing bare-500 (fix(combo): fallback to sibling model on 500 for per-model-quota providers #5976) and synthetic empty-stream cases, via isRequestScopedServerFailure in syntheticEmptyStream.ts.
  • lastError is still recorded; no lockout is written.
• A model that fails every stream mid-way is still broken, so these failures are counted per provider/connection/model (accountFallback/postOutputFailureStreak.ts). The lock is recorded when 3 arrive in a row with no completed stream in between. A stream that completes with 200 resets the count, and a streak older than 10 min starts over.
• buildExhaustionOptions now reuses the markAccountUnavailable option type instead of repeating it, so auth.ts shrinks by 7 lines.

Unchanged

• A 5xx before any output, including a combo peek that sees the error before content and fails over.
• 429 / 404 model lockouts.
• Connection cooldown for connection-scoped providers.
• The combo quality-failure lockout.

File-size ceilings

stream.ts (+1), chatCore.ts (+3) and chatHelpers.ts (+1) only gain irreducible call-site wiring. The ceilings are bumped in file-size-baseline.json, with a _rebaseline_… entry explaining why. The logic lives in streamTiming.ts, postOutputFailureStreak.ts and syntheticEmptyStream.ts.

Tests

• tests/unit/stream-failure-after-output-no-model-lockout.test.ts:
  • isolated post-output 5xx → no lockout, connection active, lastErrorType recorded;
  • three in a row → lockout; a completed stream in between resets the streak; streak keys and expiry;
  • pre-output 5xx and post-output 429 → lockout kept;
  • the stream registry: no output before a content chunk or after a role-only chunk, output after a content chunk;
  • the finalizer forwards outputEmitted;
  • a real in-stream error frame, in passthrough and translate modes: an error after content counts as output, an error frame alone does not.
• Also run: typecheck:core, check-open-sse-typecheck, check-api-typecheck, check-file-size, and ~900 neighbouring unit tests (lockout, stream, chat, combo). The only failures are the same ones on the base without this change.
• End-to-end with a local OpenAI-compatible mock and a single-target combo:
  • Before: a mid-stream error locked the model and the next request got 503 all targets were skipped.
  • After: the next request succeeds, a pre-output error still locks, and three mid-stream failures in a row lock (isolated ones with successes in between never do).

⚠️ base-red inherited: #15100

[diegosouzapw]

Thanks @QuangBlue — merged into release/v3.8.52; it ships in the next release.