allthingssecurity opened a new pull request, #28783: URL: https://github.com/apache/camel/pull/28783
# Description [CAMEL-26431](https://issues.apache.org/jira/browse/CAMEL-26431) Follow-up of CAMEL-26328 (#28751), asked for in its review: `ThrottlingExceptionRoutePolicy` now matches its exceptions the same way as the failover load balancer, `onException` and `doCatch`. The policy checked its exceptions with `exchange.getException(type)`, which goes through `ObjectHelper.getException`: that looks at the suppressed exceptions first (CAMEL-6406, a general API change) and then at the causes. So a failure counted towards opening the circuit when the exception the exchange failed with was not listed but one of its suppressed exceptions was. Since CAMEL-25114 (4.23.0) an exception thrown in a `doFinally` block is added as a suppressed exception to the exception of the `doTry` block, so a cleanup step that throws a listed type counts the failure, while an `onException` for that type in the same route does not match it. CAMEL-25114 also made a throwing `onWhen` of a `doCatch` keep the original exception as a suppressed exception of the predicate's exception. Changes: - `ThrottlingExceptionRoutePolicy.hasFailed` matches the listed types against the exception and its causes only, with `ObjectHelper.createExceptionIterable` (the walk `DefaultExceptionPolicyStrategy`, `CatchProcessor` and, since #28751, `FailOverLoadBalancer` use). Without a list every failure counts, as before. - Docs: two sentences on the route policy page on what is matched. - Upgrade guide (4.24, next to the failover entry): the `doFinally` and `onWhen` cases, and, as examples, the other cases where Camel or a processor puts a listed exception as a suppressed exception of the exception the exchange fails with, which no longer count: an `onException` block that fails while it handles the exception (`FatalFallbackErrorHandler`), a redelivery whose last attempt fails with a different exception than the first one, a failing `onCompletion` in `modeBeforeConsumer` or saga compensation, and a processor that adds one itself (try-with-resources). (Other sources, such as a failing `onPrepareFailure` processor, behave the same; the list says "for example".) The guide names the `onWhen` case next to the `doFinally` case (both since 4.23) and says that, unlike them, the others are not 4.23 regressions but an intentional change of older behaviour, so that the policy matches exceptions as `onException` and `doCatch` do. The way back: add the type of the exception t he exchange fails with to `exceptions`, or leave `exceptions` empty to count every failure. Tests: - New `ThrottlingExceptionRoutePolicySuppressedExceptionTest` (camel-core, 8 tests, no sleeps). Each route has its own policy with `java.io.IOException` listed and a threshold of 1, and each test asserts the exception the exchange fails with (and its suppressed exception) before it asserts the failure and success counts and the state of the circuit. - Not counted (the circuit stays closed): a `doFinally` that throws an `IOException` after the `doTry` block threw an `IllegalStateException`, an `onException(IOException)` block that fails with an `IllegalStateException`, a redelivery that fails with an `IllegalStateException` after a first attempt that failed with an `IOException`, and a processor that throws an `IllegalStateException` with an `IOException` added as suppressed (as try-with-resources does). These 4 fail on main and pass with the change. - Controls, passing on main as well: an `IOException` thrown directly, an `IOException` as the cause of an `IllegalStateException`, an `IOException` from `doTry` with an `IllegalStateException` from `doFinally` (all counted), and a policy without exceptions (every failure counts). - The new class 20 times in one JVM: 160 tests, 0 failures. - camel-support, and the route policy, throttling, load balancer and failover tests of camel-core and camel-management (`org.apache.camel.support.**`, `org.apache.camel.throttling.**`, `*Throttl*Test`, `*RoutePolicy*Test`, `*Suppressed*Test`, `*LoadBalanc*Test`, `*FailOver*Test`): camel-support 145 tests, camel-core 804, camel-management 20. 81 throttling, route policy, load balancer and failover classes (168 tests) pass. Three failures, none caused by this change: `RouteWatcherReloadChangedRoutesTest` fails the same way with the policy of main in my local build, and `ManagedThrottlingExceptionRoutePolicyTest` / `ManagedThrottlingInflightRoutePolicyTest` counted MBeans of other tests that ran in parallel in the same JVM and pass when run alone. The formatter and import-sort plugins ran and changed nothing. Backport: the `doFinally` and `onWhen` cases need CAMEL-25114, which is only on main and 4.23.0, and the change is visible to routes (see the upgrade guide), so I leave any backport to the reviewers, as for #28751. # 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-26431) filed for the change (usually before you start working on it): [CAMEL-26431](https://issues.apache.org/jira/browse/CAMEL-26431). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built the core modules and ran the tests above, including the formatter and import-sort plugins. No generated file changes. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 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]
