Preserve Azure Responses stream errors after HTTP 200

[dani29]

Summary

Preserve terminal Azure Responses API errors that arrive inside an already-open HTTP 200 SSE stream.

Root cause

Azure can accept a streaming Responses request with HTTP 200, emit normal lifecycle events, and then send a terminal error or response.failed event. The error details are nested in the event payload. Bifrost's native Responses paths did not normalize that shape consistently, so downstream callers could receive an empty model-run error even though the stream contained provider error information.

Change

• Add one shared Responses stream-error normalizer.
• Reuse it for both create-stream and retrieve-stream Responses paths.
• Preserve nested error type, code, and message.
• Provide a non-empty fallback message when Azure sends empty error details.
• Add an HTTP-200 Azure-shaped SSE regression test and focused unit coverage.
• Add ResponsesResponseError.Type to the schema.

This keeps the outer HTTP status unchanged: a Bifrost HTTP 200 stream is not treated as a successful model completion when a terminal error event is received.

Validation

• go test ./providers/openai ./providers/vllm ./schemas
• go vet ./providers/openai ./providers/vllm ./schemas
• git diff --check

ref REI-3301

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 03bedb2c-8095-4875-b513-9369ddeb0c3a

📥 Commits

Reviewing files that changed from the base of the PR and between 2ed4dd9 and 37f5d85.

📒 Files selected for processing (6)

• core/providers/openai/errors.go
• core/providers/openai/errors_test.go
• core/providers/openai/openai.go
• core/providers/openai/responseslifecycle.go
• core/providers/openai/streamtruncation_test.go
• core/schemas/responses.go

Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review.

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes

  • Improved handling of streaming errors from OpenAI and Azure Responses APIs.
  • Preserved provider error types, codes, and messages across in-stream failures.
  • Added clearer fallback messages when error details are unavailable.

• Tests

  • Added coverage for Azure-style errors, response failures, and truncated streams.

Walkthrough

The change adds shared normalization for OpenAI Responses stream errors. It preserves top-level and nested error fields, applies the converter to both streaming paths, extends the response error schema, and adds regression coverage.

Changes

Responses stream error handling

Layer / File(s)	Summary
Error contract and normalization core/schemas/responses.go, core/providers/openai/errors.go	ResponsesResponseError now preserves an optional top-level Type. responsesStreamError normalizes top-level and nested error fields and creates fallback messages.
Streaming path integration core/providers/openai/openai.go, core/providers/openai/responseslifecycle.go	Responses streaming handlers use responsesStreamError for error and failed events.
Error normalization validation core/providers/openai/errors_test.go, core/providers/openai/streamtruncation_test.go	Tests cover Azure-shaped errors, response failures, empty details, and terminal errors after HTTP 200 responses.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: ⚪ Minimal · up to 37f5d

This localized change preserves provider error details for terminal streaming failures without changing the outer HTTP status, with focused regression coverage and normal validation completed; no actionable merge-blocking risk remains.

Possibly related PRs

• maximhq/bifrost#5165: Both changes modify OpenAI Responses streaming error handling and related normalization.

Suggested reviewers: akshaydeo

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly identifies the main change: preserving Azure Responses stream errors received after an HTTP 200 response.
Description check	✅ Passed	The description explains the problem, root cause, implementation, testing, affected behavior, and related issue, but omits several template checklist sections.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[dani29]

Investigation note

The Azure failure mode is an in-band stream failure, not an HTTP transport failure:

1. Azure opens the Responses SSE request with HTTP 200.
2. It emits normal lifecycle events such as response.created.
3. It can then emit a terminal error or response.failed event whose details are nested under the event payload.
4. If those nested fields are not normalized, downstream code sees the misleading {"message":""}.

This PR keeps the outer HTTP 200 unchanged and preserves the terminal semantic error instead: type, code, message, plus a non-empty fallback when Azure sends empty details. The same normalizer is used by both native Responses create-stream and retrieve-stream paths.

The regression test reproduces the wire shape with response.created followed by an Azure-style nested error event. It does not claim that every such event is an Azure service-side HTTP 429; it ensures Bifrost does not discard whatever provider error Azure delivered inside the already-open stream.

Validation passed locally:

• go test ./providers/openai ./providers/vllm ./schemas
• go vet ./providers/openai ./providers/vllm ./schemas
• git diff --check

[dani29]

human note: hey folks, ran into this issue with Bifrost consuming SSE OpenAI Streaming from Azure, where we ran out of quota. The stream returns 200 Status Code, but the request hides the quote denied in the payload. This issue should fix it and surface the error properly.