Exception Behaviour without errorChannel on inbound adapters - spring-integration

Question

I have int-aws:sqs-message-driven-channel-adapter on which if I set the errorChannel, the downstream exceptions go there.
However, when I don't set an errorChannel, the exception does not get logged. It does not go to the errorChannel which is expected. Is there a way, that such exceptions at least get logged? Is there a default errorlogger which can simply log such errors?
UPDATE
Posting XML and DSL config as per the comments. The error is simulated in the persistence layer by setting null for a #NotBlank field on the ServiceObject.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:int="http://www.springframework.org/schema/integration"
xmlns:int-aws="http://www.springframework.org/schema/integration/aws"
xmlns:int-jpa="http://www.springframework.org/schema/integration/jpa"
xmlns="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/integration http://www.springframework.org/schema/integration/spring-integration.xsd
http://www.springframework.org/schema/integration/jpa https://www.springframework.org/schema/integration/jpa/spring-integration-jpa.xsd
http://www.springframework.org/schema/integration/aws https://www.springframework.org/schema/integration/aws/spring-integration-aws.xsd">
<int:channel id="serviceLogChannel">
<int:interceptors>
<int:wire-tap channel="loggingChannel"/>
</int:interceptors>
</int:channel>
<int-aws:sqs-message-driven-channel-adapter sqs="amazonSQS"
auto-startup="true"
channel="serviceLogChannel"
id="sqsMessageDrivenChannelAdapter"
queues="${app.queue-name}"
max-number-of-messages="10"
visibility-timeout="5"
wait-time-out="20"
error-channel="errorChannel"/>
<int:chain input-channel="serviceLogChannel">
<int:json-to-object-transformer type="ServiceObject"/>
<int-jpa:outbound-channel-adapter entity-class="ServiceObject"
persist-mode="PERSIST"
entity-manager-factory="entityManagerFactory">
<int-jpa:transactional/>
</int-jpa:outbound-channel-adapter>
</int:chain>
<int:logging-channel-adapter log-full-message="true"
logger-name="tapInbound"
id="loggingChannel"/>
<int:service-activator input-channel="errorChannel" expression="#reThrow.rethrow(payload)" order="100"/>
</beans>
The ReThrow service-activator:
#Component
public class ReThrow {
public void rethrow(Exception exception) throws Exception {
throw exception;
}
}
The DSL config for the same is :
#Configuration
public class IntegrationConfiguration {
#Bean
public MessageProducer createSqsMessageDrivenChannelAdapter(
AmazonSQSAsync amazonSQSAsync,
MessageChannel serviceChannel,
MessageChannel errorChannel,
#Value("${app.queue-name}") String queueName) {
SqsMessageDrivenChannelAdapter adapter =
new SqsMessageDrivenChannelAdapter(amazonSQSAsync, queueName);
adapter.setVisibilityTimeout(5);
adapter.setWaitTimeOut(20);
adapter.setAutoStartup(true);
adapter.setMaxNumberOfMessages(10);
adapter.setOutputChannel(serviceChannel);
adapter.setErrorChannel(errorChannel);
adapter.setMessageDeletionPolicy(SqsMessageDeletionPolicy.NO_REDRIVE);
return adapter;
}
#Bean
public IntegrationFlow messageProcessingFlow(
MessageChannel serviceChannel, EntityManagerFactory entityManagerFactory) {
return IntegrationFlows.from(serviceChannel)
.transform(Transformers.fromJson(ServiceObject.class))
.handle(
Jpa.outboundAdapter(entityManagerFactory)
.entityClass(ServiceObject.class)
.persistMode(PersistMode.PERSIST),
e -> e.transactional())
.get();
}
#Bean
public IntegrationFlow errorProcessingFlow(MessageChannel errorChannel) {
return IntegrationFlows.from(errorChannel)
.handle(
m -> {
throw (RuntimeException) m.getPayload();
})
.get();
}
#Bean
public MessageChannel serviceChannel() {
return MessageChannels.publishSubscribe().get();
}
}

Answer 1

The SqsMessageDrivenChannelAdapter is fully based on the SimpleMessageListenerContainerFactory from Spring Cloud AWS and that one just delegates to a listener we provide. Looking to the code there is just no any error handling. So, the best way to deal with it at the moment to explicitly set an error-channel="errorChannel" and it is going to be logged via default logger subscribed to that global errorChannel.
And yes: it is not expected to go to the errorChannel by default. I'm not sure that there is such an official claim in our docs. Probably better to think about it as "no error channel by default", so it is up to underlying protocol client to handle thrown errors. Since there is no one there, then we don't have choice unless set error channel explicitly.