allthingssecurity opened a new pull request, #29590: URL: https://github.com/apache/camel/pull/29590
# Description [CAMEL-26710](https://issues.apache.org/jira/browse/CAMEL-26710) Backport of #29406 to `camel-4.22.x`. Watermark tracking of the Split EIP was released in 4.22.0, so 4.22.x has the same hang. The split callback stored the watermark and then called the original callback, with no try/finally. When the resume strategy failed in `updateLastOffset` (for example `SingleNodeKafkaResumeStrategy` with a producer that was closed), the callback was never called, the reactive executor only logged the exception, the caller blocked forever and the exchange stayed in flight until the CamelContext was stopped. A `watermarkExpression` that throws on an item hung the split the same way. The code, test and EIP doc hunks are a straight cherry-pick of the commit merged on main (7dad7adffd26), byte-identical: - the split callback sets the exception on the exchange and always calls the callback; - a `watermarkExpression` that throws fails its item; - the watermark is cached only after it is stored, so a redelivered exchange routes the items again instead of skipping them all. The upgrade-guide hunk is new: on main the note is in the 4.24 guide, which this branch does not have, so here it goes in the 4.22 guide under "Upgrading from 4.22.2 to 4.22.3" (same text), since with `synchronous()` the next split now processes the items again when the watermark could not be stored. Because of that hunk this is not a pure cherry-pick and needs a normal review. The project rule is that the upgrade-guide entry of a backport goes on main; this branch already carries entries of its own in that section (such as the camel-jpa one), and I can add the same text to the 4.22.3 section of the 4.22 guide on main in a small docs PR, or drop the hunk here, whichever you prefer. Tests on `camel-4.22.x` (offline): `SplitterWatermarkStoreFailureTest` 4/4; together with `SplitterWatermarkTest` 400/400 over 20 runs; camel-core `*Split*Test` 312 run, 0 failures, 6 skipped. Negative control: on `camel-4.22.x` without the fix the new tests 4/4 time out (the split never completes). # Target - [x] I checked that the commit is targeting the correct branch (this is a backport to `camel-4.22.x`) # 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 of `camel-4.22.x` with the formatter and import-sort plugins and ran the tests above; 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]
