Add an option to receive MessageId as String rather than UUID

[ivanfomkin]

Type: Bug

Component:
"SQS"

Describe the bug
I'm try to work with yandex cloud with spring-cloud-aws 3.0.1 and I'm get error when I'm send and receive messages from Yandex Message Queue:
java.lang.IllegalArgumentException: Invalid UUID string: 92898073-7bd6a160-5797b060-54a7e539 (any random String)
For receiving message root cause is:

java.lang.IllegalArgumentException: Invalid UUID string: 92898073-7bd6a160-5797b060-54a7e539
	at java.base/java.util.UUID.fromString1(UUID.java:280) ~[na:na]
	at java.base/java.util.UUID.fromString(UUID.java:258) ~[na:na]
	at io.awspring.cloud.sqs.support.converter.SqsHeaderMapper.toHeaders(SqsHeaderMapper.java:156) ~[spring-cloud-aws-sqs-3.0.1.jar:3.0.1]
	at io.awspring.cloud.sqs.support.converter.SqsHeaderMapper.toHeaders(SqsHeaderMapper.java:57) ~[spring-cloud-aws-sqs-3.0.1.jar:3.0.1]

When I'm try to send message to my queue I'm gett this root stacktrace (but messages success posting to queue)

Caused by: java.lang.IllegalArgumentException: Invalid UUID string: cbc2063e-e13308bd-4ff0b3a3-b36398c6
	at java.base/java.util.UUID.fromString1(UUID.java:280) ~[na:na]
	at java.base/java.util.UUID.fromString(UUID.java:258) ~[na:na]
	at io.awspring.cloud.sqs.operations.SqsTemplate.lambda$doSendAsync$3(SqsTemplate.java:285) ~[spring-cloud-aws-sqs-3.0.1.jar:3.0.1]
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646) ~[na:na]

In AWS docs I found description of MessageId field:

A unique identifier for the message. A MessageIdis considered unique across all AWS accounts for an extended period of time.

Type: String

It's placed here: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_Message.html

In source in the place who stack trace indicates I found this code: UUID.fromString(response.messageId()
May be should not use UUID-type and just use String?

[tomazfernandes]

Hi @ivanfomkin, thanks for bringing this up.

The idea is that throughout the lifecycle of a message in the framework you can always assume the Message's id is the same as what you received when you sent and / or received the message, including any internal logging you enable in the framework. Given Spring Messaging Message expects a UUID and AWS generates one, that's what the framework converts it to.

But considering we're restricting AWS's API contract, it might be better to reconsider that. Though it doesn't look like a trivial change from the receiving side.

I'll give it some thought. If anyone has an idea please let me know.

[tomazfernandes]

Hey @ivanfomkin.

I think from the feature perspective this shouldn't be too hard, in the sense that we can have some toggle in SqsHeaderMapper to add AWS's id as either the Spring Message UUID or add it as a separate header, both for sending and receiving messages.

The tricky part though is that there are parts of the code that rely on the messageId being in the Spring Message ID.

One part that comes to mind is in the SqsTemplate when receiving messages - it uses the message id to correlate with the BatchDeletionResult.Entry. So that logic would have to be changed to look for probably the separate Header, and if not found use the Message id.

So we'd need to take an overall look to see if there's anywhere else where we could run into problems with this change.

But overall, given we do have a good test coverage on that and the feature would be opt-in, I'd be inclined to give it a shot and see how it goes and if any other tests break with this change.

How do you feel about that? Would you be willing to contribute a PR for this?

Thanks.

[luanrjjj]

I would like try this issue. This this issue seems to be a good opportunity to learn the code and tests.

[tomazfernandes]

Hey @luanrjjj, sure, give it a shot. Let me know if you have any questions. Thanks.

[jm0514]

Hi @tomazfernandes,
I've reviewed this issue and would like to work on a fix for it. I'll follow the suggestions discussed above.
Could you please assign this to me?

[injae-kim]

Fix PR: #1433 👍