allthingssecurity opened a new pull request, #27108: URL: https://github.com/apache/camel/pull/27108
# Description [CAMEL-25153](https://issues.apache.org/jira/browse/CAMEL-25153) `CaffeineAggregationRepository` and `EhcacheAggregationRepository` implement `RecoverableAggregationRepository`, and recovery is on by default. But their recovery methods work on the correlation keys of the aggregations in progress, which is the defect CAMEL-24622 fixed for camel-infinispan: - `remove` deletes the entry of the correlation key, so nothing is kept for recovery. - `confirm(exchangeId)` removes an exchange id, which is never a key of the cache. - `scan` returns `getKeys()`, the correlation keys of the open groups, and `recover` loads such a group. So the recover task of the Aggregate EIP sends every aggregation that is still open when it runs (the first run is one second after start, then every `recoveryInterval`) with `CamelRedelivered=true`. It does this at every run until `maximumRedeliveries`, and after that it tries the dead letter channel at every run. The group is then sent once more when it really completes. A completed exchange whose processing fails is never recovered. This change uses the same design as CAMEL-24622 for Infinispan. A completed exchange is kept in the same cache under a `camel-recovery:<exchange id>` key until it is confirmed. `scan` reports those exchange ids (none when recovery is disabled), `recover` reads them, `confirm` removes them, and `getKeys` reports only the aggregations in progress. One difference from Infinispan: `remove` stores the exchange it is given, not the entry it removed from the cache. When an incoming message completes a group, the aggregator does not `add` the final state before `remove`, so the entry in the cache does not contain that message. This is the same fix as CAMEL-24946 for `KeyValueAggregationRepository`, and it matches `JdbcAggregationRepository`. `InfinispanAggregationRepository` still stores the removed entry. I did not change it here because its tests need Infinispan. Upgrade guide note for 4.23: aggregations in progress are no longer sent by the recovery task, failed completed exchanges are recovered, and the cache holds one entry per completed exchange until it is confirmed. Tests: - New `CaffeineAggregationRepositoryRecoverTest` and `EhcacheAggregationRepositoryRecoverTest`: the Aggregate EIP with `recoveryInterval=100` (only to keep the test fast), one group that stays open and one group completed with `completionSize(2)`. The step after the aggregator fails the first time. The test expects the completed group once, then once more with `CamelRedelivered=true`, and nothing else. After three more runs of the recover task (counted in a subclass, waited for with Awaitility), nothing more has been sent, the recovered exchange is confirmed, and `getKeys()` is only the open group. - In both `*AggregationRepositoryOperationTest` classes, `testConfirmExist`, `testScan` and `testRecover` encoded the correlation-key behaviour and are reworked as they were for Infinispan. New tests: `testScanWithoutRecovery`, `testRecoverDoesNotReturnAggregationInProgress` and `testGetKeysIgnoresExchangesToRecover`. - Without the change, 6 of the 15 aggregation repository tests fail in each module. The route test receives the open group `c` as its first message, and the operation tests fail on the scanned correlation keys. - With the change, all camel-caffeine tests pass (84, 0 failures) and all camel-ehcache tests pass (66, 0 failures). Found with a TLA+ model of the aggregator, the repository and the recover task. The model delivers a partial group and never re-delivers a failed completed group with the current key space, and both properties hold with the fix. I then reproduced both cases with the real classes. # 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]
