allthingssecurity opened a new pull request, #27160: URL: https://github.com/apache/camel/pull/27160
# Description [CAMEL-25211](https://issues.apache.org/jira/browse/CAMEL-25211) Two defects in the non-optimistic `remove` with recovery enabled, which is the default configuration of both Hazelcast aggregation repositories. `HazelcastAggregationRepository.remove` put the entry it removed from the map into the completed map. When an incoming message completes a group, the Aggregate EIP aggregates it and calls `remove` without adding the final state to the repository first, so that entry is the group before the last message. A completed exchange whose processing failed was recovered without the message that completed the group. This is what CAMEL-24946 fixed for `KeyValueAggregationRepository` and CAMEL-25164 for Infinispan. The optimistic branch of the same method already stores the given exchange. `ReplicatedHazelcastAggregationRepository` keeps its groups and completed exchanges in `ReplicatedMap`s, but its `remove` ran a Hazelcast transaction on the IMaps of the same names. The group was never in that IMap, so the removed value was null, the put failed with "value can't be null", and the transaction was rolled back: every group of two or more messages failed to complete and stayed in the repository. This change: - `HazelcastAggregationRepository.remove` puts the holder marshalled from the given exchange into the completed map, in the same transaction. - `ReplicatedHazelcastAggregationRepository.remove` puts the given exchange into the replicated completed map and then removes the group from the replicated map, under the per-key lock that `add` uses. A `ReplicatedMap` cannot take part in a transaction; writing the completed exchange first means a failure in between leaves it to recovery. Tests: - New `HazelcastAggregationRepositoryRecoverTest`, for both repositories. A group of three messages is completed, the step after the aggregator fails once, and the recovered exchange must hold all three messages. - Without the change the test fails: the IMap repository recovers `a+b` instead of `a+b+c`, and the replicated one fails the completion with the rolled back transaction. - With it, all camel-hazelcast tests pass: 233 tests. `HazelcastAggregationRepositoryRoutesTest.checkAggregationFromTwoRoutes` is flaky on main too (a second exchange in its first run, then it passes on rerun), with and without this change. # 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). # 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 and tested the affected module, including the formatter and import-sort plugins. 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]
