Cloud9 `NotFoundException` deserialization error

[ewbankkit]

Describe the bug

The Cloud9 NotFoundException error is not being deserialized correctly.
A JSON response of

{"__type":"NotFoundException","className":"NotFound","code":404,"message":"Unable to find [289ff5bae55240f89da9cddb1951fda4] in database."}

does not return a types.NotFoundException, instead at the Go SDK level we get

request failed with unretryable error https response error StatusCode: 400, RequestID: 1c2eb684-9adb-4f01-9b37-8c5940f45472, deserialization failed, failed to decode response body, json: cannot unmarshal number into Go struct field .Code of type string

Expected Behavior

Expected types.NotFoundException to be returned as a Go error.

Current Behavior

See above.

Reproduction Steps

Call cloud9.DescribeEnvironments() with a non-existent environment ID.

Possible Solution

No response

Additional Information/Context

No response

AWS Go SDK V2 Module Versions Used

github.com/aws/aws-sdk-go-v2/service/cloud9 v1.22.7

Compiler and Version used

go version go1.20.10 darwin/amd64

Operating System and version

macOS Ventura 13.6

[RanVaknin]

Hi @ewbankkit ,

Thanks for reaching out. I logged the raw response before it gets deserialized by the SDK and it looks like this:

SDK 2024/02/06 11:28:52 DEBUG Response
HTTP/2.0 400 Bad Request
Content-Length: 123
Content-Type: application/x-amz-json-1.1
Date: Tue, 06 Feb 2024 19:28:52 GMT
X-Amzn-Requestid: REDACTED

{"__type":"NotFoundException","className":"NotFound","code":404,"message":"Unable to find [nonExistentEnvId] in database."}

As you can see, two separate sets of errors are being sent, one in the headers and one in the body. Based on the JSON protocol cloud9 uses, the error code should be only specified in the header (string) whereas the service models their code field as an integer as shown in the body.

I'll raise this internally and see how we can address this.
Thanks again,
Ran~

[lucix-aws]

The root cause here is that we're making the incorrect assumption that code is a special field in awsjson errors meant to hold the modeled error's name. This is true for __type but the former can technically be modeled as one of the members on the error as well. We're not accounting for that, which we'll need to fix.