SQS - Fail to receive messages when attributeNames and messageAttributeNames requested

[ekofler]

Describe the bug

When ReceiveMessageRequest sent with both attributeNames and messageAttributeNames , response handling fail with DeserializationException .

AWS JAVA SDK with same request attributes works fine.

Expected behavior

To receive message with its attributes and messageAttributes

Current behavior

fail with error

Exception in thread "main" aws.smithy.kotlin.runtime.serde.DeserializationException: expected class aws.smithy.kotlin.runtime.serde.xml.XmlToken$Text; found class aws.smithy.kotlin.runtime.serde.xml.XmlToken$BeginElement (<StringValue (6)>)
	at aws.smithy.kotlin.runtime.serde.xml.XmlPrimitiveDeserializer.deserializeValue(XmlPrimitiveDeserializer.kt:85)
	at aws.smithy.kotlin.runtime.serde.xml.XmlPrimitiveDeserializer.deserializeString(XmlPrimitiveDeserializer.kt:49)
	at aws.smithy.kotlin.runtime.serde.xml.XmlMapDeserializer.deserializeString(XmlDeserializer.kt)
	at aws.sdk.kotlin.services.sqs.transform.MessageDocumentDeserializerKt.deserializeMessageDocument(MessageDocumentDeserializer.kt:55)
	at aws.sdk.kotlin.services.sqs.transform.ReceiveMessageOperationDeserializerKt.deserializeReceiveMessageOperationBody(ReceiveMessageOperationDeserializer.kt:102)
	at aws.sdk.kotlin.services.sqs.transform.ReceiveMessageOperationDeserializerKt.access$deserializeReceiveMessageOperationBody(ReceiveMessageOperationDeserializer.kt:1)
	at aws.sdk.kotlin.services.sqs.transform.ReceiveMessageOperationDeserializer.deserialize(ReceiveMessageOperationDeserializer.kt:45)
	at aws.sdk.kotlin.services.sqs.transform.ReceiveMessageOperationDeserializer$deserialize$1.invokeSuspend(ReceiveMessageOperationDeserializer.kt)

Steps to Reproduce

See example

       val sqsClient = SqsClient {
            region = "us-east-1"
            credentialsProvider = DefaultChainCredentialsProvider()
        }

        sqsClient.receiveMessage(ReceiveMessageRequest {
            queueUrl = "https://sqs.us-east-1.amazonaws.com/myaccount/myqueue"
            attributeNames = listOf(QueueAttributeName.All)
            messageAttributeNames = listOf("All")
        }).messages?.forEach {
            println(it)
        }

Possible Solution

No response

Context

No response

AWS Kotlin SDK version used

1.7

Platform (JVM/JS/Native)

JVM

Operating System and version

linux and macos

[lauzadis]

I'm not able to replicate this. My SDK properly deserializes a ReceiveMessageResponse and I'm able to access messages with all of the attributes.

Can you share more information about your environment? Also, the AWS SDK for Kotlin version 1.7 doesn't exist.

[wlogan-omnidian]

I've run into this myself, using Kotlin 1.8.10 and this Maven dependency declaration:

    <dependency>
      <groupId>aws.sdk.kotlin</groupId>
      <artifactId>sqs-jvm</artifactId>
      <version>0.27.2-beta</version>
    </dependency>

In my experience, the bug only occurs when attempting to deserialise messages when the request includes both system attributes (attributeNames = listOf(QueueAttributeName.All)) and message attributes (messageAttributeNames = listOf("All")). Requesting either independently appears to work fine.

Debugging through the deserialisation it appears that the code expecting to process the system attributes is also being given the message attributes to deserialise, and of course those have a different schema in the response.

[ekofler]

I'm using kotlin 1.7.0 with JDK 11.
As wlogan mention, it happen when you're using both attributeNames and messageAttributeNames.

[lauzadis]

Thanks! I was able to replicate the issue after another try and we're working on a fix now.

[lauzadis]

A fix has been merged in smithy-lang/smithy-kotlin#879, you can expect this to be shipped in next week's release. Thanks for the report!

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

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.