allthingssecurity opened a new pull request, #27159: URL: https://github.com/apache/camel/pull/27159
# Description [CAMEL-25210](https://issues.apache.org/jira/browse/CAMEL-25210) `CassandraAggregationRepository` (and `NamedCassandraAggregationRepository`) implement `RecoverableAggregationRepository`, and recovery is on by default. But the table only holds the aggregations in progress, so the recovery methods work on the wrong rows. This is the defect CAMEL-24622 fixed for Infinispan and CAMEL-25153 for Caffeine and Ehcache: - `remove` deletes the row of the correlation key, so nothing is kept for recovery. - `scan` returns the exchange ids of the aggregations in progress, and `recover` loads such an aggregation. - `confirm(exchangeId)` deletes the aggregation in progress that has this exchange id. So the recover task of the Aggregate EIP sends an aggregation that is still open (the first run is one second after start, then every `recoveryInterval`) with `CamelRedelivered=true`. When that exchange is processed, `confirm` deletes the open aggregation, and the messages that arrive later start a new group. A completed exchange whose processing fails is never recovered. This change uses the same design as for Infinispan, Caffeine and Ehcache. A completed exchange is kept in the same table under the aggregation key `camel-recovery:<exchange id>` until it is confirmed, so the table does not change. `remove` writes the exchange it is given (see CAMEL-24946) before it deletes the aggregation. `scan` reports the exchange ids of those keys (none when recovery is disabled), `recover` reads them, `confirm` deletes them, and `getKeys` reports only the aggregations in progress. The `DELETE ... IF EXCHANGE_ID = ?` statement is no longer used. Tests: - New `CassandraAggregationRepositoryRecoveryTest`, a unit test that runs the repository against an in-memory table behind a mocked `CqlSession`. An open group must not be sent by the recover task, and a completed group whose processing fails once must be recovered with all its messages and confirmed. - Without the change the test fails: the open group is sent twice, and the failed completed group is not recovered. With it, the camel-cassandraql unit tests pass (8 tests). - `CassandraAggregationRepositoryIT` and `NamedCassandraAggregationRepositoryIT` encoded the old key space (`testConfirmExist`, `testScan`, `testRecover`), and are reworked. They compile, but I could not run them: they need Cassandra in Docker, which was not available here. The upgrade guide gets a note: `scan` no longer returns open groups, and the table now also holds completed exchanges until they are confirmed. # 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]
