Skip to content

fix: convert Bedrock streaming error to APIStatusError#1488

Open
xodn348 wants to merge 1 commit into
anthropics:mainfrom
xodn348:fix/bedrock-streaming-error-1477
Open

fix: convert Bedrock streaming error to APIStatusError#1488
xodn348 wants to merge 1 commit into
anthropics:mainfrom
xodn348:fix/bedrock-streaming-error-1477

Conversation

@xodn348
Copy link
Copy Markdown
Contributor

@xodn348 xodn348 commented May 4, 2026

Fixes #1477

What

When Bedrock returns a non-200 status code inside an SSE event (e.g. internalServerException), the AWSEventStreamDecoder now yields an "error" ServerSentEvent instead of raising a raw ValueError. The existing Stream.__stream__() error handler catches this event and converts it to a proper APIStatusError, matching the behavior of the non-Bedrock streaming path.

Why

Previously, _parse_message_from_event raised ValueError on non-200 event status codes. This was problematic because:

  • ValueError is a generic exception that doesn't carry HTTP status info
  • Users cannot catch it with the SDK's standard error hierarchy (except APIStatusError, except BadRequestError, etc.)
  • It bypasses the SDK's existing error-handling infrastructure entirely

How

Changed _parse_message_from_event to return ServerSentEvent | None instead of str | None. On non-200 status codes, it returns a ServerSentEvent(event="error", data=...) with the Bedrock error details formatted as an Anthropic API error body. The iter_bytes/aiter_bytes methods now yield these events directly, allowing the Stream.__stream__() error handler to convert them to APIStatusError via _client._make_status_error().

Verification

  • Build: pass
  • Tests: pass (41 passed — 6 new + 35 existing)
  • Lint: pass (ruff check)
  • Type check: pass (pyright — 0 errors)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bedrock streaming SSE events errors are not handled gracefully

1 participant