allthingssecurity opened a new pull request, #29406: URL: https://github.com/apache/camel/pull/29406
# Description [CAMEL-26710](https://issues.apache.org/jira/browse/CAMEL-26710) A split with `resumeStrategy` stores the watermark in its own callback and then calls the original callback, with no try/finally. When the resume strategy fails in `updateLastOffset`, `persistWatermark` rethrows, the original callback is never called, and the reactive executor only logs "Error executing reactive work ... This exception is ignored". The caller blocks forever in `DefaultAsyncProcessorAwaitManager.await`, the exchange stays in flight, and only stopping the CamelContext releases it. Every later split on the route hangs the same way. With `synchronous()` the exception reaches the caller instead. One way to get there is `SingleNodeKafkaResumeStrategy` after a route stop/start: it keeps the producer it closed on stop, so `updateLastOffset` throws "Cannot perform operation after producer has been closed" (fixed separately in CAMEL-26709). The SPI declares `updateLastOffset` with `throws Exception`, so any strategy can do this. A `watermarkExpression` that throws on an item hangs the split the same way, as it is evaluated in the callback of each item. This is the same pattern as CAMEL-26301 (an exception escaping an async callback in `TokenizerProcessor`). Change (`Splitter`): - The split callback sets the exception on the exchange (`catch (Throwable)`, as around `onCompletion` in `MulticastProcessor.doDone`) and always calls the original callback in `finally`. - A `watermarkExpression` that throws fails the item (the exception is set on the sub-exchange), so `stopOnException`, `maxFailedRecords` and `errorThreshold` apply as for any failed item. - The watermark is cached in memory only after the resume strategy stored it. The failed exchange can now be redelivered by the error handler; with the watermark already cached, the redelivery skipped every item, stored nothing and succeeded. Now the items are routed again (at least once), as when the split is aborted. - `split-eip.adoc` (and its catalog copy): one sentence added to the watermark note. The watermark feature exists only on `main`, so there is nothing to backport. Tests (`SplitterWatermarkStoreFailureTest`, a subclass of the existing `SplitterTestResumeStrategy` whose `updateLastOffset` throws): - storing the watermark fails: `asyncSend(...).get(5s)` returns the exchange with the exception, and nothing is stored; - the next split processes the same items again once the store works; - with `maximumRedeliveries(1)` and a store that fails once, the redelivery routes the 3 items again and stores the watermark; - a `watermarkExpression` that throws: the split completes with a `RuntimeExpressionException`. On main all 4 tests time out (the exchange never completes). Mutants: without the cache change the 2 redelivery/next-split tests fail; without the expression guard the expression test times out. 20 runs of the new class with `SplitterWatermarkTest`: 420/420. camel-core `*Split*Test`: 349 run, 0 failures, 6 skipped (offline build with the formatter and import-sort plugins; no source changes from them). # 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-26710](https://issues.apache.org/jira/browse/CAMEL-26710). # 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 split tests; the catalog copy of split-eip.adoc is updated by hand to match. 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]
