MessagingConverter's in SqsMessageListenerContainerFactory's is ignored

[mayleaf]

Type: Bug

Component: SQS

Description

I've identified an issue with message converter handling in AbstractListenerAnnotationBeanPostProcessor that prevents custom message converters from being applied to @SqsListener methods.

Environment

• io.awspring.cloud:spring-cloud-aws-sqs:3.4.2
• io.awspring.cloud:spring-cloud-aws-sns:3.4.2
• Spring Boot 2.7.18

Problem

The issue occurs in the initialization flow of the AbstractListenerAnnotationBeanPostProcessor:

1. The configureDefaultHandlerMethodFactory(DefaultMessageHandlerMethodFactory handlerMethodFactory) method receives a DefaultMessageHandlerMethodFactory instance
2. Its methodArgumentResolvers is initialized with a converter created by createCompositeMessageConverter()
3. While SqsMessageListenerContainerFactory allows registering custom message converters, these converters are overridden by the composite converter created in step 2

Expected Behavior

Custom message converters registered in SqsMessageListenerContainerFactory should be used to resolve method arguments in @SqsListener annotated handlers, enabling proper deserialization of complex types (e.g., LocalDateTime with JavaTimeModule).

Actual Behavior

The custom message converters are overridden by createCompositeMessageConverter(), causing deserialization failures for messages that require custom converters.

Code Sample

@SqsListener("${aws.sqs.queue-name}")
public void handle(@Payload CustomEventType event, Acknowledgement acknowledgment) {
    // Handler logic
}

@ToString
@Getter
class CustomEventType {
    private LocalDateTime createdAt;
    private String publisherId;
    private List<OtherCustomType> elems;
}

Steps to Reproduce

1. Register a custom message converter (e.g., with JavaTimeModule) in SqsMessageListenerContainerFactory
2. Create an @SqsListener method with a @Payload parameter containing LocalDateTime fields
3. Send a message to the queue
4. Observe deserialization failure despite the custom converter being registered

Impact

This prevents using custom serialization/deserialization logic with @SqsListener methods, requiring workarounds or manual message parsing.

Possible Solution

The createCompositeMessageConverter() method could be modified to include or respect custom converters registered in the container factory, rather than overriding them.

Would appreciate any guidance on the intended design or if this should be addressed in a future release. Happy to provide additional details or submit a PR if helpful.

[tomazfernandes]

Hi @mayleaf, thanks for the detailed report.

One important clarification: the message converter configured via SqsMessageListenerContainerFactory (ContainerOptions) is applied in the MessageSource component. Concretely, AbstractConvertingMessageSource takes the converter from ContainerOptions and uses it to deserialize the payload:

spring-cloud-aws/spring-cloud-aws-sqs/src/main/java/io/awspring/cloud/sqs/listener/source/AbstractMessageConvertingMessageSource.java

Lines 62 to 68 in 6ab5e41

	@Override
	public void configure(ContainerOptions<?, ?> containerOptions) {
	this.messagingMessageConverter = (MessagingMessageConverter<S>) containerOptions.getMessageConverter();
	this.messageConversionContext = maybeCreateConversionContext();
	this.acknowledgementMode = containerOptions.getAcknowledgementMode();
	configureMessageSource(containerOptions);
	}

If the incoming message does not carry type information (for example if the JavaType header/message attribute is absent), the MessageSource cannot determine the target type and conversion falls back to the handler argument resolution path.

Could you confirm how messages are produced (SqsTemplate vs another service), and whether a type hint is present on the received message (e.g., the JavaType header/message attribute)?

The fix here is to infer the target payload type from the @SqsListener method at endpoint/container setup time, and set that on the ContainerOptions converter via payloadTypeMapper. That way conversion works even when type headers are missing, and it also lets Interceptors and ErrorHandlers access the converted payload.

In the meantime, workarounds are:

• register your ObjectMapper as a bean so auto configuration picks it up, or
• provide an SqsListenerConfigurer and use registrar.manageMessageConverters(...) to add/configure converters used by @SqsListener.

[mayleaf]

Thanks for the quick turnarounds and your supports.
As you said, I tried SqsListenerConfigurer, and it works.