When ConverseStream experiences throttling during the streaming of the response, the error codes are returned camelCase (instead of PascalCase) like serviceUnavailableException, throttlingException.
The ConverseStream docs tell:
The exception returned is wrapped with CompletionException, so you need to invoke Throwable.getCause() to retrieve the underlying exception.
Unfortunately, the SDK does not deal with the camelCase and unmarshals to a BedrockRuntimeException ("Unknown exceptions will be thrown as an instance of this type.") instead of the known and documented ServiceUnavailableException, or ThrottlingException, making this a an unexpected and special case for retry/ exception handling. See the attached debug screenshot:
Bedrock Runtime team refused to fix the error code on their end in the response post-launch. Can you handle camelCase on the SDK side for a uniform handling of the exception mid-stream and outside of stream, so retry mechanisms work on capacity and throttling issues?
Regression Issue
Expected Behavior
All mid-stream errors are unmarshalled to their corresponding exception types (e.g. throttlingException -> ThrottlingException).
Current Behavior
All mid-stream errors are all unmarshalled to BedrockRuntimeException.
Reproduction Steps
Run many converseStream requests in parallel on a busy day/ time.
Possible Solution
No response
Additional Information/Context
No response
AWS Java SDK version used
2.28.0
JDK version used
Corretto-21.0.8.9.
Operating System and version
MacOS 26.1
When ConverseStream experiences throttling during the streaming of the response, the error codes are returned camelCase (instead of PascalCase) like
serviceUnavailableException,throttlingException.The
ConverseStreamdocs tell:Unfortunately, the SDK does not deal with the camelCase and unmarshals to a
BedrockRuntimeException("Unknown exceptions will be thrown as an instance of this type.") instead of the known and documentedServiceUnavailableException, orThrottlingException, making this a an unexpected and special case for retry/ exception handling. See the attached debug screenshot:Bedrock Runtime team refused to fix the error code on their end in the response post-launch. Can you handle camelCase on the SDK side for a uniform handling of the exception mid-stream and outside of stream, so retry mechanisms work on capacity and throttling issues?
Regression Issue
Expected Behavior
All mid-stream errors are unmarshalled to their corresponding exception types (e.g.
throttlingException->ThrottlingException).Current Behavior
All mid-stream errors are all unmarshalled to
BedrockRuntimeException.Reproduction Steps
Run many
converseStreamrequests in parallel on a busy day/ time.Possible Solution
No response
Additional Information/Context
No response
AWS Java SDK version used
2.28.0
JDK version used
Corretto-21.0.8.9.
Operating System and version
MacOS 26.1