Do not put a null message attribute when contentType is unsupported

[anjeongkyun]

📢 Type of change

• Bugfix
• New feature
• Enhancement
• Refactoring

📜 Description

SnsHeaderConverterUtil.getContentTypeMessageAttribute returns null when the contentType header is neither a MimeType nor a String, and the caller put that return value straight into the attribute map:

if (MessageHeaders.CONTENT_TYPE.equals(messageHeaderName) && messageHeaderValue != null) {
    messageAttributes.put(messageHeaderName, getContentTypeMessageAttribute(messageHeaderValue));
}

The map then carries contentType -> null. PublishRequest.builder().messageAttributes(map).build() accepts it, so nothing fails until the request is marshalled:

software.amazon.awssdk.core.exception.SdkClientException
Caused by: java.lang.NullPointerException: Cannot invoke
  "software.amazon.awssdk.core.SdkPojo.sdkFields()" because "pojo" is null

That happens before the call leaves the client, so the publish fails entirely rather than just dropping the header.

The loop already has a branch for header types SNS cannot carry: it logs a warning and leaves the header out. This change routes the unsupported contentType down that same path, and pulls the warning into a small private method so both places use it.

The SQS side handles the same case: SqsHeaderMapper.getContentTypeMessageAttribute is not @Nullable and falls back to an empty string attribute. I kept SNS consistent with its own loop rather than copying that, since skipping the header matches what this class already does for values it cannot convert. Happy to switch it to the empty-string fallback if you would rather the two modules line up.

This is not a regression. The same code was in TopicMessageChannel before it was extracted into SnsHeaderConverterUtil in #1574.

💡 Motivation and Context

toSnsMessageAttributes is used by the sync (TopicMessageChannel), batch (DefaultSnsMessageConverter) and async (DefaultSnsPublishMessageConverter) publish paths, so any application setting a contentType header that is not a String or MimeType loses the message on all three.

💚 How did you test it?

Added sendMessage_withUnsupportedContentTypeHeader_shouldNotSetItAsMessageAttribute to TopicMessageChannelTest, alongside the existing header conversion tests. It fails on current main (the attribute map contains the key with a null value) and passes with the change.

I also confirmed the marshalling failure end to end before writing the fix, by sending a request built from the converted attributes through a real SnsClient pointed at an unreachable endpoint, which produced the SdkClientException above.

spring-cloud-aws-sns passes in full (119 tests). I ran the repo-wide unit tests too: the only failure is S3InboundChannelAdapterTests.s3InboundChannelAdapter, which fails the same way on an unmodified main here.

📝 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

Reference docs are unchanged because the documented behaviour is unaffected: supported contentType values are converted exactly as before.

On breaking changes: an application that today sends an unsupported contentType gets a failed publish, and after this it gets a successful publish with a warning and no contentType attribute. Nothing that works today changes.

🔮 Next steps

None.