Add configurable UUID conversion for non-AWS SQS-compatible services

[jm0514]

Add configurable UUID conversion for non-AWS SQS-compatible services

📢 Type of change

• Bugfix
• New feature
• Enhancement
• Refactoring

📜 Description

Added configurable support for SQS-compatible cloud services (like Yandex Message Queue) that use non-UUID MessageId formats. The framework now supports both UUID and non-UUID MessageId handling through a new configuration option.

Configuration:

# For AWS SQS (default behavior)
spring.cloud.aws.sqs.convert-message-id-to-uuid=true

# For non-AWS SQS-compatible services (Yandex, etc.)
spring.cloud.aws.sqs.convert-message-id-to-uuid=false

💡 Motivation and Context

Solves #814

💚 How did you test it?

• Unit Tests: Added comprehensive tests for SqsHeaderMapper and MessageHeaderUtils

📝 Checklist

• I reviewed submitted code
• I added tests to verify changes
• I updated reference documentation to reflect the change
• All tests passing
• No breaking changes

🔮 Next steps

[maciejwalkowiak]

Passing a random UUID does not feel right. Perhaps MessagingMessageHeaders can have id set as String instead of UUID? cc @tomazfernandes

[jm0514]

Thanks for the suggestion! Updated to generate UUID from Message ID instead of random UUID.

[tomazfernandes]

Hey @jm0514, thanks for the PR!

Perhaps MessagingMessageHeaders can have id set as String instead of UUID? cc @tomazfernandes

@maciejwalkowiak, the issue there is that the MessagingMessageHeaders inherits from MessageHeaders from Spring, and that one requires an UUID type in the constructor.

Might be worth raising with the Spring Messaging team?

In the meantime, I think we can make the solution simpler if we leverage the fact that most ID-related operations are made through the MessageHeaderUtils#getId method, which already returns a String.

Instead of requiring a configuration change to support other ID types, we could simplify the logic by trying to parse the UUID, and if it fails we add the new header as suggested in the PR.

Then in the MessageHeaderUtils#getId method, we check for the header first, and return either that, or the Spring Message ID if the former is absent.

The caveat would be that for non UUID ids, the result from getting the ID header directly would be a random UUID, but I don't think there's a way around it with the existing MessageHeaders implementation, so properly documenting the behavior should suffice. And since we don't currently support that anyway, we wouldn't really need a breaking change.

What do you folks think?