allthingssecurity opened a new pull request, #29665: URL: https://github.com/apache/camel/pull/29665
# Description [CAMEL-26824](https://issues.apache.org/jira/browse/CAMEL-26824) Follow-up of #29525 (CAMEL-26741), with the list asked for in its review, all but the reactive executor, which gets a JIRA and PR of its own (I will file it): the worker cannot fail an exchange it does not know about, so that fix belongs in the catches of `MulticastTask` and needs its own parallel, streaming and transacted tests. #29525 and the camel-bean follow-up #29575 are merged; this is one commit on main, with no code in common with #29575 (both add to the 4.24 upgrade guide, in different entries). CAMEL-26741 makes the processor adapters fail the exchange with an `Error` that is not a `VirtualMachineError`, and leaves a `VirtualMachineError` as before. These processors had the same pattern (`catch (Exception)` with `callback.done(..)` in `finally`), so an `Error` of the code they call (an `AssertionError`, a `LinkageError`, a custom `Error`) let the route continue as if the step had succeeded, or reached the caller after the callback: - `EvaluateExpressionProcessor`: the expression of a `recipientList`; - `MulticastProcessor`: the synchronous branch of `process` (`split`, `multicast` and `recipientList` with `synchronous=true`), and the catch around `createProcessorExchangePairs` in `doProcess` (for example an `Error` of the split expression), which now goes through `doDone` as an exception does, so the aggregation strategy is completed and removed from the exchange (in the default mode the `Error` already failed the exchange through the engine, but skipped `doDone`); - `DataTypeProcessor` and `DelegatingDataTypeProcessor`: a data type transformer; - `AbstractApiProducer` (camel-support): the producer of a component built on the API component framework runs the invocation on a thread of the component. An `Error` of an API method called by reflection is already wrapped (`Method.invoke`) and fails the exchange; an `Error` outside that call (when the client is created, a client method that a producer calls directly, `interceptResult`) was lost in the `Future` of `submit()`, after the callback had completed the exchange as a success. Change: each of them catches a `VirtualMachineError` first and throws it on (as before, and as the adapters of #29525 do), and sets any other `Throwable` on the exchange; the callback stays in `finally`. In `AbstractApiProducer` an exception is still wrapped as before. Also fixed, found on the way: `DelegatingDataTypeProcessor` called the callback twice when the `CamelDataType` exchange property was missing (once before its `return`, once in `finally`). Docs: the 4.24 upgrade guide entry of CAMEL-26741 and the "An Error thrown by a processor" section of `error-handler.adoc` (both from #29525) now name these places (the error handler page without the API producer case, which is narrower). Not changed, left for that follow-up: the reactive executor's worker (`DefaultReactiveExecutor`) and `MulticastTask` catch only exceptions, so a non-VM `Error` of an `AggregationStrategy` or of the iterator of a streaming split still reaches the worker (with `parallelProcessing`, it is lost in a `Future`); `CamelInternalProcessor.processTransacted` (the same pattern, rarely reached, as the error handlers catch `Throwable` first); `ContractAdvice` (input/output type transformers, catches `Exception`). A `VirtualMachineError` is left as before at the five places changed here, as in #29525 (on the thread of an API component it is lost in the `Future`, as before). One case stays different, for the follow-up too: a `VirtualMachineError` thrown by an API method called by reflection is wrapped by `ApiMethodHelper.invokeMethod` in a `RuntimeCamelException`, so it fails the exchange as an exception, where a bean method's no longer does since #29575. Tests, new `SiblingProcessorsThrowErrorTest` (calls the processors with an `AssertionError` and a `StackOverflowError`, as `ProcessorThrowsErrorTest` of #29525 does for the adapters): - `EvaluateExpressionProcessor`, `DataTypeProcessor`, `DelegatingDataTypeProcessor`: an `Error` fails the exchange (wrapped in a `CamelExecutionException`) and the callback is called once; a `StackOverflowError` is thrown on after the callback, as before (`EvaluateExpressionProcessor`, `DataTypeProcessor`; these two pass before the change too, as controls); - `delegatingDataTypeProcessorCallsTheCallbackOnceWithoutTheDataTypeProperty`; - `synchronousSplitFailsTheExchangeWithAnErrorOfItsExpression`: a route with `onException(AssertionError.class).handled(true)` and a synchronous split whose expression throws: the `onException` handles it and the step after the split does not run; - `splitFailsTheExchangeWithAnErrorOfItsExpression`: the same with the default split; both split tests also check that the split completed its aggregation strategy (`doDone`), which fails without the change in `doProcess`; - `recipientListFailsTheExchangeWithAnErrorOfItsExpression`: the same with a `recipientList` whose expression throws; and in `AbstractApiProducerTest`, `testErrorOutsideTheReflectiveCallFailsTheExchange` (the `Error` is thrown by `doInvokeMethod`, as a producer that calls its client directly can do). On main without the change (with #29525 and #29575 merged) the 7 new cases that are not controls (the 2 `StackOverflowError` cases are) and the API producer case fail; with the change they pass. In the camel-core tests (9176 run, 45 skipped) the only failure and error are unrelated: the error is `ValidatorExternalResourceTest` (it loads an XSD over the network, which timed out here) and the failure `DistributedTimeoutTest` (under load its 200 ms completion timeout discarded the group and the mock waited 30 s; no `Error` involved), which passed when run again. # 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-26824](https://issues.apache.org/jira/browse/CAMEL-26824). # 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 with the formatter and import-sort plugins and ran the camel-core tests; 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]
