CAMEL-24069: camel-spring-rabbitmq - Use consumer exception handler for async failures - #24721
Conversation
…or async failures Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
gnodet
left a comment
There was a problem hiding this comment.
Clean, well-scoped fix that aligns the spring-rabbitmq async error handling with Camel's canonical pattern.
The key improvement: DefaultEndpoint.exceptionHandler is null by default (it's an optional user-configured field), so the old code silently swallowed async errors unless the user explicitly set an exception handler on the endpoint. DefaultConsumer.exceptionHandler is always initialized to a LoggingExceptionHandler, so errors will now always be logged/handled — and the exchange context is passed through for better diagnostics.
This matches the canonical pattern used in DefaultConsumer.DefaultConsumerCallback.done(), ApiConsumerHelper, and other consumer implementations across Camel.
Claude Code review on behalf of @gnodet. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 9 tested, 29 compile-only — current: 9 all testedMaveniverse Scalpel detected 38 affected modules (current approach: 9).
|
oscerd
left a comment
There was a problem hiding this comment.
LGTM. Same improvement as the camel-sjms sibling (#24722): the async-failure path now uses consumer.getExceptionHandler().handleException("Error processing exchange", exchange, rce), routing through the consumer's exception handler with the exchange context instead of the endpoint-handler overload that dropped it. CI green.
Reviewed with Claude Code on behalf of Andrea Cosentino. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.
Claude Code on behalf of davsclaus
Summary
When
asyncConsumer=trueand an exchange fails after the listener method has already returned (async completion), the failure was silently dropped becauseEndpointMessageListenercalledendpoint.getExceptionHandler()which isnullby default, with no fallback.The fix uses
consumer.getExceptionHandler()instead, which always has a defaultLoggingExceptionHandler(set byDefaultConsumerconstructor). This matches the canonical pattern used byDefaultConsumer.DefaultConsumerCallbackand other components like camel-pulsar.The same bug in camel-sjms has been filed as CAMEL-24083.
Changes
EndpointMessageListener.java: Changed the async failure path fromendpoint.getExceptionHandler()(nullable, no fallback) toconsumer.getExceptionHandler()(always non-null)Test plan
mvn verify— 35 tests, 0 failures)