Bug: avoid committing HTTP 200 for Responses stream failures before the first downstream write

Summary

When an upstream OpenAI-compatible /v1/responses stream fails by emitting response.error or response.failed, New API can already have a 200 OK streaming response in progress. This makes client-side retry logic much harder, because transport-level success does not mean the request actually completed successfully.

Why this matters

In the Responses API, the upstream server may:

• return HTTP 200 to establish the SSE stream,
• then emit an error event such as response.error / response.failed,
• or terminate before a successful response.completed flow.

For retry-aware clients, HTTP 200 is therefore only a transport success, not a business success.

Current behavior

From a quick code read, the current OpenAI Responses streaming path eagerly starts the downstream SSE flow, and if the upstream later sends an error event, New API can no longer convert that turn into a non-200 JSON error response.

This is especially visible for:

• raw /v1/responses streaming relay
• chat-completions-via-responses streaming conversion
• Codex / Responses-backed upstreams that sometimes fail mid-stream with generic server_error payloads

Expected behavior

A narrow, low-risk improvement would be:

1. If the upstream stream fails before New API has written any downstream event, return a normal structured API error with a non-200 status instead of committing the SSE response early.
2. If the downstream stream has already started, preserve current streaming semantics and only surface/log the upstream stream error without trying to rewrite the already-committed status code.

This would let retry-capable clients make a correct decision in the important “failed before first token” case, without changing the established behavior of already-started streams.

Scope suggestion

To keep this change supplemental and low-risk, it can be limited to the OpenAI Responses streaming handlers only, instead of refactoring the generic streaming pipeline.

Notes

I am preparing a small companion PR that keeps the change localized to the Responses streaming handlers and adds regression coverage for the pre-first-write failure case.

Start by tracing the raw /v1/responses streaming relay and the chat-completions-via-responses streaming conversion in the OpenAI Responses streaming handlers. Add regression coverage for an upstream response.error or response.failed before the first downstream write, and verify that failures before writing return a structured non-200 API error while already-started streams retain their current behavior.