allthingssecurity opened a new pull request, #27120: URL: https://github.com/apache/camel/pull/27120
# Description [CAMEL-25164](https://issues.apache.org/jira/browse/CAMEL-25164) Since CAMEL-24622, `InfinispanAggregationRepository` keeps a completed exchange for recovery under a `camel-recovery:<exchange id>` key. But `remove(ctx, key, exchange)` stores the entry it removed from the cache there, and only uses the exchange passed to `remove` when the cache had no entry. 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 the entry in the cache is the group before the last message. If the processing after the aggregator fails, the recovered exchange is missing the message that completed the group. This change: `remove` stores the marshalled exchange it is given, as CAMEL-24946 did for `KeyValueAggregationRepository` and as the Caffeine and Ehcache repositories do (CAMEL-25153, #27108). The embedded and the remote repository share this code, and neither overrides `remove`, so both are fixed. Claus Ibsen pointed this out in the review of #27108. No upgrade guide entry: the recovered exchange now has the content the aggregator sent the first time, which is what recovery is meant to deliver. Tests: - New `InfinispanEmbeddedAggregationRepositoryRecoverTest`: the Aggregate EIP with `completionSize(3)` and `recoveryInterval=100` (only to keep the test fast). The step after the aggregator fails the first time. The test sends "a", "b" and "c" and expects "a+b+c", then "a+b+c" again with `CamelRedelivered=true`. - New `testRecoverTheExchangeGivenToRemove` in `InfinispanEmbeddedAggregationRepositoryOperationsTest`: the cache holds "a+b", `remove` is given "a+b+c", and `recover` returns "a+b+c". - Without the change, both new tests fail (`expected: <a+b+c> but was: <a+b>`). - With the change, the camel-infinispan-embedded tests pass: 90 tests, 0 failures. I left out `InfinispanEmbeddedClusteredConsumerTest` and the `cluster` package, because on my machine their JGroups cluster does not form ("Timed out before caches had complete views") and the fork times out. That happens in the test setup, before any repository code runs. - The remote repository tests (`InfinispanRemoteAggregationRepository*IT`) need an Infinispan container, and Docker is not available on my machine, so I did not run them. The remote repository uses the same `remove` as the embedded one. # 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 modules, 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]
