feat(sqs): allow requesting MessageAttributes on ReceiveMessage (interop-only)

[MurilloFagundes]

Summary

Enable opt-in retrieval of Amazon SQS user-defined message attributes on receive, without changing default mappers. By design, this PR is interop-only: attributes are requested from SQS when configured, and are available to custom ISqsEnvelopeMapper implementations. Built-in mappers remain unchanged.

Motivation

Amazon SQS only returns user-defined message attributes when explicitly requested (ReceiveMessageRequest.MessageAttributeNames). The transport currently never sets this field, so consumers cannot read those attributes. This PR forwards configured names to the receive request to support interoperability scenarios that rely on custom mappers.

What changed

• Added AmazonSqsQueue.MessageAttributeNames (optional).
• In ConfigureRequest, apply MessageAttributeNames only when the list is non-empty.
• Default behavior remains unchanged (no attributes requested unless configured).
• No changes to RawJsonSqsEnvelopeMapper or DefaultSqsEnvelopeMapper.

How to use

// Request All user-defined message attributes:
queue.MessageAttributeNames = new List<string> { "All" };

// Or request specific attributes:
queue.MessageAttributeNames = new List<string> { "retailerId", "commId" };

Note

The mapping of attributes received for the Envelope (headers/metadata) is handled by your custom ISqsEnvelopeMapper.

Notes

• If MessageAttributeNames is null or empty, no attributes are requested (current default).
• Using "All" requests all user-defined message attributes.
• This setting affects receive only (ReceiveMessageRequest.MessageAttributeNames); sending attributes remains unchanged and is handled by the SQS envelope mapper.
• Requesting many attributes (or "All") can increase the response payload size; use only when needed.
• System attributes (ReceiveMessageRequest.MessageSystemAttributeNames) are out of scope for this change.

Tests

• configure_request
• default_message_attribute_names_is_null_on_endpoint
• configure_request_does_not_set_message_attribute_names_when_null
• configure_request_does_not_set_when_empty_list

Backward compatibility

No breaking changes. If not configured, behavior is identical to current versions.

Documentation

Short note in the SQS transport docs explaining MessageAttributeNames and the "All" keyword.
AWS Documentation

[andbreder]

👍

[jeremydmiller]

To what end? How is this useful at all? And the configuration for this isn't readily discoverable at all from the configuration right now.

[MurilloFagundes]

Thanks for the quick feedback.

In our environment some upstream producers (non-Wolverine) put business metadata in SQS message attributes (e.g., correlationId, tenantId). SQS only returns those if requested on receive, so this PR adds a strictly opt-in switch to pass MessageAttributeNames. Defaults stay the same and nothing changes unless configured.

This is intentionally the smallest viable change to keep the transport aligned with AWS-native behavior while unblocking interop.

I intentionally kept the scope minimal. I’m happy to adjust the code (API shape/naming/placement) to match Wolverine’s conventions and make it more discoverable. What would you suggest here?

[jeremydmiller]

@MurilloFagundes What I'd mostly say is that this does no real harm, but no real good unless you know it's there. Happy to take this in, but I might ask you to send a later update to the SQS docs about the usage and maybe even a little background about why you did this. No hurry though. I'll have this out in 4.11 though.