Description
In what version(s) of Spring Integration are you seeing this issue?
5.3.1.RELEASE
Describe the bug
If the RabbitMQ Stream client throws an error, it seems that the RabbitStreamMessageHandler is catching them but not properly sending it down an errorChannel.
To Reproduce
We have a sample project that resembles our code in production. You can see we create the RabbitStreamMessageHandler as per the docs. Unfortunately, this results in a null
value for the sendFailureChannel
and sendFailureChannelName
.
By contrast if we manually set a sendFailureChannelName
to "errorChannel"
, we can see the errors thrown by the client.
@Bean
public IntegrationFlow demoOutboundChannelAdapter(
RabbitStreamTemplate myStreamTemplate, MessageChannel outboundChannel) {
return IntegrationFlow.from(outboundChannel)
.handle(RabbitStream.outboundStreamAdapter(myStreamTemplate)
.sync(true)
.sendFailureChannel("errorChannel"))
.get();
}
The error were specifically encountering (and is represented in the sample repo) is when a message is too large, it exceeds the frame_max
size. The stack trace we see looks like this (truncated):
[demo] [ scheduling-1] o.s.integration.handler.LoggingHandler : java.lang.IllegalArgumentException: Message too big to fit in one frame: 5243004
at com.rabbitmq.stream.impl.Client.checkMessageFitsInFrame(Client.java:479)
at com.rabbitmq.stream.impl.ProducerUtils$MessageAccumulatorHelper.entity(ProducerUtils.java:301)
at com.rabbitmq.stream.impl.DynamicBatchMessageAccumulator.add(DynamicBatchMessageAccumulator.java:133)
at com.rabbitmq.stream.impl.StreamProducer.doSend(StreamProducer.java:402)
at com.rabbitmq.stream.impl.StreamProducer.send(StreamProducer.java:385)
at com.rabbitmq.stream.impl.SuperStreamProducer.send(SuperStreamProducer.java:120)
at org.springframework.rabbit.stream.producer.RabbitStreamTemplate.observeSend(RabbitStreamTemplate.java:276)
...
Expected behavior
If this is expected behaviour, then it should be documented, but I doubt this is the case. I would hope the expected behaviour is to send to the default "errorChannel"
. Perhaps setting that as the default value is a reasonable fix.