CAMEL-23428: Fix flaky RabbitMQProducerInvalidExchangeIT test

[gnodet]

CAMEL-23428

The RabbitMQProducerInvalidExchangeIT.testProducer test is flaky because it asserts the direct cause of CamelExecutionException is ShutdownSignalException. However, Spring AMQP may wrap the underlying ShutdownSignalException in an AmqpException depending on timing, causing intermittent failures.

Fix: Use AssertJ's hasRootCauseInstanceOf to check the exception cause chain. This handles both cases and provides better diagnostics (full stack trace) on failure:

• Direct cause: CamelExecutionException → ShutdownSignalException
• Wrapped cause: CamelExecutionException → AmqpException → ShutdownSignalException

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• components/camel-spring-parent/camel-spring-rabbitmq

✅ POM dependency changes: targeted tests included

Modules affected by dependency changes (1)

• :camel-spring-rabbitmq

All tested modules (8 modules)

• Camel :: JBang :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: TUI
• Camel :: JBang :: Plugin :: Validate
• Camel :: Launcher :: Container
• Camel :: Spring RabbitMQ
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results

[apupier]

I think we could use https://javadoc.io/doc/org.assertj/assertj-core/3.27.7/org/assertj/core/api/AbstractThrowableAssert.html#hasCauseInstanceOf(java.lang.Class)

it will allow to have shorter code and also a better error message with the full stack trace.
Especially given that it sounds like a stab in the dark that the AMQPEXception is wrapping the shutdownexception. At least, if i tis not the case, i twill help to investigate more.

[gnodet]

Good point, thanks! Switched to assertThat(exception).hasRootCauseInstanceOf(ShutdownSignalException.class) — uses hasRootCauseInstanceOf rather than hasCauseInstanceOf since the ShutdownSignalException is the deepest cause in both the direct and wrapped scenarios. This also gives the full stack trace on failure as you suggested.

Claude Code on behalf of Guillaume Nodet