[jira] [Created] (CAMEL-25947) camel-spring-rabbitmq - with confirm=auto the producer does not wait for publisher confirms of type SIMPLE, so a message RabbitMQ negatively acknowledges or does not confirm is lost without an error

["shashank (Jira)" <ji...@apache.org>]

shashank created CAMEL-25947:
--------------------------------

             Summary: camel-spring-rabbitmq - with confirm=auto the producer does not wait for publisher confirms of type SIMPLE, so a message RabbitMQ negatively acknowledges or does not confirm is lost without an error
                 Key: CAMEL-25947
                 URL: https://issues.apache.org/jira/browse/CAMEL-25947
             Project: Camel
          Issue Type: Bug
          Components: camel-spring-rabbitmq
            Reporter: shashank
            Assignee: shashank


With the default {{confirm=auto}}, the InOnly producer ({{SpringRabbitMQProducer.processInOnly}}, main 9f839f4bcc9d) decides whether to wait for publisher confirms with {{getConnectionFactory().isPublisherConfirms()}}. In spring-rabbit 4.1.1, {{CachingConnectionFactory.isPublisherConfirms()}} is {{ConfirmType.CORRELATED.equals(confirmType)}}. A connection factory with publisher confirms of type {{SIMPLE}} answers {{isSimplePublisherConfirms()}} instead (javap of both methods), and {{SIMPLE}} is the type that {{RabbitTemplate.invoke}} plus {{waitForConfirms}} is meant for. So with {{spring.rabbitmq.publisher-confirm-type=simple}}, or {{setPublisherConfirmType(ConfirmType.SIMPLE)}}, the producer:

* puts the channel in confirm mode (the connection factory does that) but never waits for the confirm;
* completes the exchange as soon as {{basicPublish}} returns. A message that RabbitMQ negatively acknowledges (for example a full queue with {{x-overflow=reject-publish}}), or never confirms (a broker that goes down before the message is written), is lost without an error. That is what publisher confirms were configured to prevent, and the option documentation says "auto = Camel detects if the connection factory uses confirms or not".

*Fix*: {{confirm=auto}} waits when the connection factory has publisher confirms of either type ({{isPublisherConfirms() || isSimplePublisherConfirms()}}). {{RabbitTemplate.waitForConfirms(long)}} returns {{false}} only for a negative acknowledgement, so the {{TimeoutException}} of that case now says "Message negatively acknowledged by RabbitMQ". When no confirm arrives within {{confirmTimeout}}, amqp-client 5.31.0 {{ChannelN.waitForConfirms}} throws {{java.util.concurrent.TimeoutException}}, which {{RabbitTemplate}} turns into an {{AmqpTimeoutException}} (javap of both); that fails the exchange. Upgrade guide entry: such producers now wait up to {{confirmTimeout}} per message and fail on a negative acknowledgement or a missing confirm; {{confirm=disabled}} keeps the old behaviour.

*Tests*: new {{SpringRabbitMQProducerConfirmTest}}. It uses a real {{CachingConnectionFactory}} over a mocked RabbitMQ client. The mocked {{Channel.waitForConfirms(long)}} answers as the client documents: {{true}} when everything was acked, {{false}} when a message was nacked, and a {{TimeoutException}} when the timeout elapses. Three tests fail on main:
* {{negativeAcknowledgementFailsTheExchangeWithSimplePublisherConfirms}}: {{expected: <java.util.concurrent.TimeoutException> but was: <null>}};
* {{missingConfirmFailsTheExchangeWithSimplePublisherConfirms}}: {{expected: <org.springframework.amqp.AmqpTimeoutException> but was: <null>}};
* {{acknowledgedMessageIsSentWithSimplePublisherConfirms}}: {{Wanted but not invoked: channel.waitForConfirms(5000L)}}.
Two controls pass on main and with the fix: {{CORRELATED}} still waits, and no confirms means no wait.
camel-spring-rabbitmq unit tests with the fix: 11 run, 0 failures.

*How it was found*: library-contract mining. I read which {{ConnectionFactory}} method reports which confirm type in spring-rabbit 4.1.1, and checked the producer's {{auto}} detection against it.

*Affected*: main, camel-4.23.x, camel-4.22.x, camel-4.18.x and camel-4.14.x (the same {{isPublisherConfirms()}} check). I read the code on those branches but did not run the tests there.

_Filed with Claude Code on behalf of allthingssecurity._



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)