SQS ReceiveMessageWithContext: SerializationError: failed to unmarshal response error

[ainsleyclark]

Describe the bug

When bumping aws-sdk-go from v1.47.5 to latest, a large amount of SerializationError errors are returned when using the SQS ReceiveMessageWithContext method.

Although the serialisation error is a red herring, it only returns Bad Request in the response body bytes, making it nearly impssible to debug and fine out the correct 400 response code as defined in the ReceiveMessage documentation.

I'm unsure if there has been a change with SQS but it seems an update has broken backwards compatibility.

Expected Behavior

Either:

• Correct error response, or more information about why the error occurred such as response byes.
• No error.

Current Behavior

An error is returned from the request, as shown below.

SerializationError: failed to unmarshal response error
status code: 400, request id: 
caused by: UnmarshalError: failed decoding error message
00000000  42 61 64 20 52 65 71 75  65 73 74                 |Bad Request|
caused by: invalid character 'B' looking for beginning of value

Reproduction Steps

in := &sqs.ReceiveMessageInput{
	QueueUrl:              aws.String("https://sqs.eu-west-1.amazonaws.com/000000000000/event-bus-test"),
	WaitTimeSeconds:       aws.Int64(20),
	MaxNumberOfMessages:   aws.Int64(int64(10)),
	MessageAttributeNames: []*string{aws.String("All")},
	VisibilityTimeout:     aws.Int64(int64(30)),
}

res, err = q.sqs.ReceiveMessageWithContext(ctx, in)

// Returns SerializationError

Possible Solution

No response

Additional Information/Context

No response

SDK version used

v1.51.25

Environment details (Version of Go (go version)? OS name and version, etc.)

go v1.22.0

[RanVaknin]

Looking into this with priority.

[RanVaknin]

Hi @ainsleyclark ,

Thanks for your patience. We had a major re-work done with SQS not too long ago where the service migrated their protocol from SQS query (xml based) to JSON protocol. I'm wondering if this issue might be related.

Can you enable the debug logs, inspect and share with us the raw response that is sent back from the service?
You can do that like so:

	cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithRegion("us-east-1"), config.WithClientLogMode(aws.LogRequestWithBody|aws.LogResponseWithBody))
	if err != nil {
		panic(err)
	}

	client := sqs.NewFromConfig(cfg)

Thanks!
Ran~

[ainsleyclark]

Hi @RanVaknin

Thanks for your reply.

Due to constraints it may be quite difficult to enable logging to inspect the response body.
However, I'm highly confident this is the issue as we are using pafortin/goaws and they don't support JSON encoding yet (updated quite some time ago).

Is there any workaround so we can continue to keep XML or is it a hard swap?

[RanVaknin]

Hi @ainsleyclark ,

This is a hard swap. The Protocol is defined on the model level, so while you may be able to call the API directly with whichever wire protocol you choose, Since the SDK is defined based on the model, and the model can only have a single wire protocol defined, the SDK is scoped to that single protocol, which in this case is JSON.

The only other workaround I can think of is to downgrade the SDK but its not recommended. The solution here is to get 3rd party pafortin/goaws SQS clone to implement the new wire protocol.

Thanks,
Ran~

[github-actions]

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.