allthingssecurity opened a new pull request, #29792: URL: https://github.com/apache/camel/pull/29792
# Description [CAMEL-26888](https://issues.apache.org/jira/browse/CAMEL-26888) Follow-up of #29525 (CAMEL-26741, an `Error` of a processor fails the exchange) and #29406 (CAMEL-26710, the split does not hang when the watermark cannot be evaluated or stored). Three places still caught only `Exception`, so an `Error` that is not a `VirtualMachineError` (such as a `NoClassDefFoundError` of a class or function used there) was not handled as an exception: - the watermark expression of a split (`Splitter.WatermarkProcessorExchangePair.done`): CAMEL-26710 fails the item when the expression throws, as a throw there made the split exchange hang; an `Error` still escaped to the thread that drove the split (the caller got the `Error`) and left the split exchange inflight; - the aggregation strategy of an `enrich` (`Enricher`): it runs in the callback of the resource exchange, so an `Error` escaped that callback to the caller, the exchange stayed inflight, and the completions of the resource exchange did not run; - the aggregation strategy of a `pollEnrich` (`PollEnricher`): the `Error` escaped `process`, so the error handler failed the exchange with it (wrapped in a `CamelExecutionException`, not the `CamelExchangeException` "Error occurred during aggregation"), and the completions of the polled resource never ran: a polled file was not released, so a later poll could not get it again. Change: these three catch `Throwable` where they caught `Exception`, with a `VirtualMachineError` rethrown first, so a `VirtualMachineError` is left as before, as in the processors since CAMEL-26741 (`DelegateSyncProcessor`, `AsyncProcessorConverterHelper`). - `enrich` and `pollEnrich`: the exchange fails with `CamelExchangeException("Error occurred during aggregation")`, as for an exception of the strategy, and the resource is released as failed. - split watermark: the item fails, as for an exception of the watermark expression, and the split exchange fails with it. As for such an exception since CAMEL-26710, the split exchange is marked exhausted, so an `onException` of the route does not get it. The callback wrapper of CAMEL-26710 (`wrapCallback`), which already catches every `Throwable`, is unchanged. So is the worker of the reactive executor, which also catches only exceptions: a worker that swallowed an `Error` would leave a synchronous caller waiting for ever (no callback comes, and the `Error` is gone), so such an `Error` is caught where it is thrown, as here. Docs: two more bullets in the 4.24 upgrade-guide section of CAMEL-26866 (no new section), since an `Error` in an `enrich` strategy (such as a test assertion) is now caught by a catch-all `onException`, `doCatch` or dead letter channel. The list of places in `error-handler.adoc` is edited by #29665: once it is merged I will add `enrich`, `pollEnrich` and the split watermark to it in this PR. Tests: - new `SplitterWatermarkThrowsErrorTest`: the watermark expression (a Simple custom function) throws a `NoClassDefFoundError`; the split completes and fails with it (wrapped by the exchange, as any `Error`), stores no watermark, and nothing stays inflight; - new `EnricherAggregationStrategyThrowsErrorTest`: the aggregation strategy of an `enrich` and of a `pollEnrich` throws a `NoClassDefFoundError`; the exchange fails with `CamelExchangeException` caused by it, and nothing stays inflight; and a file polled by a `pollEnrich` whose strategy throws an `Error` once is released, so the next request gets it. Without the change the new tests fail on main: in the enrich and watermark tests the `Error` reaches the caller and the exchange stays inflight until the context stops; the pollEnrich test gets a `CamelExecutionException` instead of the `CamelExchangeException`, and the file test fails at its second request, as the file of the first one was not released. With it the camel-core tests pass on the final commit (9197 run, 0 failures, 1 error in `ValidatorExternalResourceTest`, which needs the network, 45 skipped). Other aggregation strategies, for a follow-up JIRA (I will file it): an `Error` of `AggregationStrategy.timeout` or `onCompletion` on a completion timeout of the Aggregate EIP passes three catches of `Exception` and cancels the purge task of the aggregator for good; `AggregateProcessor.doAggregation` and `ClaimCheckProcessor` are synchronous (the error handler fails the exchange). The multicast family is in #29665 and its follow-up. # 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-26888](https://issues.apache.org/jira/browse/CAMEL-26888). # 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. 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]
