[0xtbug]

Summary

When a combo using the round-robin strategy served a streaming response, the
endpoint returned a 500 even though the upstream provider call succeeded and quota
was available. The combo's validateResponseQuality() peeks streaming bodies via
response.body.getReader() to detect empty/content-filtered streams. That call
locks result.body and hands back a replay stream in quality.clonedResponse.

The priority strategy already returns quality.clonedResponse ?? result, but the
round-robin path returned the original (now-locked) result. Next.js then failed to
pipe it (TypeError: Invalid state: The ReadableStream is locked,
ERR_INVALID_STATE) and surfaced a 500. Non-combo chat was unaffected because it
never runs quality validation.

This change makes the round-robin success path return quality.clonedResponse ?? result,
mirroring the priority strategy.

Before

After

Related Issues

• Closes #
• Related to

Validation

• npm run lint
• npm run test:unit
• npm run test:coverage
• Coverage is still >= 60% for statements, lines, functions, and branches
• SonarQube PR analysis is green or any remaining issues are explicitly documented below

Tests Added Or Updated

• No automated tests added in this PR. The change is a one-line return-value fix in the
  round-robin combo path; recommend a follow-up streaming-combo regression test that asserts
  the returned Response body is unlocked and forwards buffered + remaining SSE chunks.

Coverage Notes

• Touches open-sse/services/combo.ts only. The fix is exercised by any combo using the
  round-robin strategy with a streaming (text/event-stream) response — it now returns the
  replay stream produced by validateResponseQuality instead of the locked original.
• No coverage regression expected; no lines were removed, only the returned value was corrected.

Reviewer Notes

• Risk area: streaming response lifecycle in combo.ts. The replay stream
  (buildReplayResponse) re-emits buffered prefix chunks then forwards the original reader,
  so byte-for-byte output is preserved.
• Behavior now matches the priority strategy path (return { ok: true, response: quality.clonedResponse ?? result }).
• The 499 client-disconnect early-return in round-robin is unchanged and safe — it lives in
  the !result.ok branch, so validateResponseQuality never ran and the body was never locked.
• Manual validation: send a streaming request through a round-robin combo and confirm a 200
  with the full streamed body instead of a 500.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[diegosouzapw]

Merged into release/v3.8.25 🎉 — thanks @0xtbug! Excellent root-cause: validateResponseQuality() locks result.body via getReader() and hands back the replay in quality.clonedResponse, and the round-robin path was returning the locked original (priority already did the right thing). I added a regression test that fails (body locked) without your one-line fix and passes with it, crediting you as author. Validated: typecheck + lint clean. Ships in v3.8.25. 🙌