Event stream exceptions always report a 500 status code

[rhernandez35]

Describe the bug

Exceptions received in event streaming callbacks always report a 500 status code:

• Transforming the Message into a Java object
• Noticing the event is an error
• Building a shim SdkHttpFullResponse for exception translation purposes
• NOT setting a status code on the shim response object

If an event is a normal event, it's given a synthetic 200 status code. Otherwise, it's not given one at all and we eventually get a fallback code of 500. This impacts some customers' error reporting. If we're synthetically generating a code for streaming exceptions, it should follow the expectations of the protocol in use. For rest-json, that would be whatever status code is explicitly mapped to the structure. For the AWS/JSONs, that would be a 400 for client errors and a 500 for server errors.

Note that event streaming elements cannot actually have status codes associated with them. Any event streaming response will necessarily be associated with a request that has successfully initiated and flushed a headers section with a 200 status code.

Regression Issue

• [ ] Select this option if this issue appears to be a regression.

Expected Behavior

The synthetic status code generated by the SDK for an exception delivered in an event streaming callback should match the protocol expectations and not use a generic 500.

Current Behavior

A 500 status code is reported as a fallback.

Reproduction Steps

Call an event streaming service and have it report an error in its event stream.

Possible Solution

Populate the synthetic status code field for an event streaming exception with a value that matches what the protocol expects. Alternatively, just don't report a status code at all.

Additional Information/Context

Reported by a KDS user calling SubscribeToShard

AWS Java SDK version used

Unknown

JDK version used

N/A

Operating System and version

N/A

[rhernandez35]

Looking at the generated code for event streaming, it seems that none of the ExceptionMetadata instances are generated with statusCode attributes set. That would explain why we're ultimately hitting that fallback 500 in AwsJsonProtocolErrorUnmarshaller.

[debora-ito]

@rhernandez35 we are aware of the issue, we have an internal task to fix this. Can't give exact timelines, but it's high in the priority list.

[debora-ito]

Fixed via #5670, released in SDK version 2.28.28. Closing.

[github-actions[bot]]

This issue is now closed. Comments on closed issues are hard for our team to see. If you need more assistance, please open a new issue that references this one.