Error handler for async RabbitListeners (Mono, Future, suspend) not acking message when ErrorHandler returns `null`

[jensbaitingerbosch]

In what version(s) of Spring AMQP are you seeing this issue?

3.2.8

Describe the bug

When having an async Rabbit listener which throws an exception and the error handler returns null (assuming that the exception had been somehow mitigated (e.g. triggering a retry), the message is not acked but 'hangs' unacked for all eternity (or until the rabbit server times out).

In contrast using the same logic with a sync listener, the message is acked.

To Reproduce

Send a message to an the queue theQueue and the message stays anacked. Send a message to theOtherQueue and the message is consumed.

@Component
class Consumer() {

    @RabbitListener(queues = ["theQueue"], errorHandler = "errorHandler" )
    suspend fun consumeRabbitMessage(message: Message): Unit? {
        throw RuntimeException("something went wrong while consuming the message")
    }

       @RabbitListener(queues = ["theOtherQueue"], errorHandler = "errorHandler" )
   fun consumeRabbitMessageSync(message: Message): Unit? {
        throw RuntimeException("something went wrong while consuming the message")
    }
}

@Component
class ErrorHandler : RabbitListenerErrorHandler {
    override fun handleError(
        msg: Message?,
        ch: Channel?,
        msg2: org.springframework.messaging.Message<*>?,
        ex: ListenerExecutionFailedException?
    ): Any? {

        //asume the error was handled internally
        return null
    }
}

Expected behavior

The message should be acked (analog behaviour to a sync listener)

[artembilan]

The sycn listener uses an auto-ack by default. Therefore, as long as no errors are thrown from the handler, the message is ack'ed.
The async mode is MANUAL, so even if no errors the ack is not done because manual is asked.
You may mitigate the problem with explicit channel.basicAck(msg.getMessageProperties().getDeliveryTag(), false) call from your ErrorHandler.
At the same time I see your point, and we probably need to ack automatically when result of the RabbitListenerErrorHandler is null and we are in async mode.
There point is that null in the async interactions is not good: we always have to produce some CompletableFuture or Mono.
But we cannot judge end-user logic and should be defensive for such a situation.

[jensbaitingerbosch]

thanks for the quick fix, in that case its the (sync) RabbitListenerErrorHandler returning the null and in the end is should behave similarly as the sync variant. As far as I understood, the documentation of the (sync) RabbitListenerErrorHandler, null is a valid return value for the error hander signalizing that there is nothing to reply to back to the messags sender.