allthingssecurity opened a new pull request, #29527: URL: https://github.com/apache/camel/pull/29527
# Description [CAMEL-26757](https://issues.apache.org/jira/browse/CAMEL-26757) Follow-up of CAMEL-26714 (#29409), as agreed in its review: a test that runs real camel-chaos rules and the exchange sanitizer on the same routes. This is the "Together with the others" step of the validation in `design/exchange-sanitizer.adoc`, for chaos. `ManagedSanitizerTest` in camel-management already covers the sanitizer next to a hand-written `StepHook`, JMX, the tracer and the backlog debugger; this one uses the rules of camel-chaos itself. Where the test lives: in camel-chaos, with `camel-sanitizer` added in test scope. camel-sanitizer only brings camel-support and camel-core-model, which camel-chaos already depends on (its JUnit dependency is optional), so nothing heavy is added to the test classpath. The tests of camel-sanitizer are in camel-core, but camel-core cannot use camel-chaos in test scope: camel-chaos uses camel-main in test scope, and camel-main uses the test-jar of camel-core in test scope, so the reactor would have a cycle. What this does not cover, on purpose: JMX, the tracer and the backlog debugger. `ManagedSanitizerTest` in camel-management already runs the sanitizer with all three and a hand-written hook that fails a step, including the path where JMX instruments a step whose error handler can redeliver (the hook is then asked by `DefaultChannel.StepHookProcessor`). Adding camel-management to the test scope of camel-chaos would switch JMX on for its camel-main tests (`camel.main.jmxEnabled` defaults to true, and JMX comes on once camel-management is on the classpath), so this test stays with chaos and the sanitizer only. `ChaosWithSanitizerTest` (`@CamelSanitizer`, so any violation that no `@ExpectSanitizerViolation` expects fails the test): - `step=work error until=1` with an error handler that redelivers: the rule fails the first attempt, the redelivery calls the processor once. The sanitizer checked 2 calls (the redelivered `work` and the send after it), not the attempt that chaos failed, and reports nothing. - `step=unhandled error` on a route with `noErrorHandler()`, where the channel of the step asks the chaos hook: the exchange fails with `ChaosException`, the processor is never called, and the sanitizer checked no call. - `step=work delay duration=5ms` (a control): `work` is called once after the delay; 2 checked calls, no report. - `endpoint=direct:receiver duplicate`: the producer is called twice within one call of the step `toReceiver`, whose callback is called once. The producer returns before the first send is done (it routes through the receiving route, `doneSync` false), so the completion of the first send makes the second send. The sanitizer checked 3 calls (`toReceiver` once, the step of the receiving route once per send) and reports nothing. - `endpoint=mock:duplicated duplicate`: the same with a producer that completes each send synchronously, so the thread of the step makes the second send. 1 checked call, no report. - A processor that throws instead of calling its callback, on a step whose first attempt `step=throws error until=1` fails: reported once as `THREW_BEFORE_CALLBACK` at step `throws`, for the redelivered call only. Test only; no change to main code, docs or generated files. With camel-sanitizer on the test classpath of camel-chaos, the sanitizer also switches itself on for the contexts with profile `dev` in the existing tests (`ChaosActivationTest`, `ChaosMainTest`, `ChaosScenarioMainTest`, `ChaosDevConsoleTest`, `ChaosLifecycleStartupTest`), as documented for profile `dev`: they log its WARN that it is on, and they reported no violation. Tests: the new class (6 tests) passed 20 of 20 runs in one JVM (120/120), and the camel-chaos module tests pass (810, 0 failures). Two negative controls, neither part of this PR: - `SendHelper` changed to call the callback of a send that a hook duplicates after the first of the two sends too: only the sanitizer catches it: both duplicate tests fail with `COMPLETED_TWICE`, at step `toReceiver` (asynchronous first send) and at step `toMock` (synchronous), while the mocks still get two messages each. - `StepHelper` changed to call the processor also when the hook failed the step: the three tests with an `error` rule fail on the processor counters (the call-count assertions after them are not reached); the `delay` and `duplicate` tests are not affected. _Claude Code on behalf of allthingssecurity_ # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-26757](https://issues.apache.org/jira/browse/CAMEL-26757). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [x] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
