allthingssecurity opened a new pull request, #26788: URL: https://github.com/apache/camel/pull/26788
# Description [CAMEL-24943](https://issues.apache.org/jira/browse/CAMEL-24943) With a `RecoverableAggregationRepository`, an aggregated exchange could be sent twice without any failure. The completing thread removes the group from the repository under the aggregation lock, which moves it into the recovery store, and only registers it in `inProgressCompleteExchanges` later, in `onSubmitCompletion` after the lock is released. If the recover task scanned in between, it re-delivered the exchange as well. With optimistic locking, timeout completions were exposed too. This is a remaining case of the race addressed by CAMEL-6097 and CAMEL-8010. This change: - Before `remove` on a recoverable repository, the aggregated exchange is marked as "being completed". The mark is a per-id counter in a separate map, so with optimistic locking a thread that lost the compare-and-set can't clear the winner's mark. - The recover task treats marked ids as in progress. `onSubmitCompletion` clears the mark after registering the id. - The mark is also cleared whenever the exchange is not submitted: `remove` throws, the exchange is discarded, the aggregation fails after the completion, or the group is force-discarded. So those exchanges are still recovered, and delivery stays at-least-once. Tests: new `AggregateRecoverInProgressTest` covers batch completion with the normal lock, optimistic locking by size, and optimistic locking by timeout. Without the fix, all 3 fail (recover called 1 time instead of 0). With the fix they pass. The aggregator suites and the camel-management aggregator tests pass. Note: this and #PR_F3 (CAMEL-24944) both change `AggregateProcessor.doAggregation`'s signature, so whichever merges second needs a small rebase. Keep CAMEL-24944's version of those lines; sending a completed group already clears this change's mark. Found with a TLA+ model of the Aggregate EIP (a group delivered twice), then reproduced against 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. -- 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]
