allthingssecurity opened a new pull request, #28074: URL: https://github.com/apache/camel/pull/28074
# Description [CAMEL-25759](https://issues.apache.org/jira/browse/CAMEL-25759) The EventBridge consumer adds its SQS queue as a target of the rule when it starts, with a new random target id each time (`"camel-eb-" + UUID...`), and removes that target when it stops. With an auto-created queue each consumer has its own queue, so that is fine. With a queue given by the user (`queueUrl`), the rule gets one target per consumer for the same queue: 1. two consumers that share the queue (two instances of the application, or two routes) add two targets for it. EventBridge sends a matching event to every target of the rule, so every event is put on the queue twice and routed twice; 2. a consumer that is not stopped cleanly (JVM killed, container OOM) leaves its target on the rule, and the next start adds a second one. From then on every event is put on the queue twice, with nothing in the log. Each such restart adds one more copy, until the rule reaches the limit of 5 targets and the consumer fails to start. This change gives the target of a user-provided queue an id derived from the queue ARN (`camel-eb-` + 32 hex characters of its SHA-256). PutTargets replaces a target with the same id, so every start and every consumer of the queue updates the same target. That target now stays on the rule when the consumer stops: other consumers may still use the queue, and the queue keeps collecting the events of the rule while no consumer runs (before, the events published during a restart never reached the queue). An auto-created queue is not changed: random target id, target removed on stop, queue deleted with `deleteQueueOnShutdown=true`. For review: keeping the target of a user-provided queue on stop reverses the removal that CAMEL-23207 added (the component page and `testUserProvidedQueueNotDeletedOnShutdown` said so). The two changes go together: with one shared id but removal on stop, the first consumer that stops would remove the target the others still use. If you prefer to keep the removal for a queue that only one consumer uses, it could go behind an option instead. Not changed: a target that the user added to the rule for the same queue under an id of their own (for example from infrastructure as code) is still a second target, as before. The behaviour change for user-provided queues (the target is kept on stop) is in the 4.24 upgrade guide, with a note that a target an earlier version left behind (`camel-eb-` + 8 characters) has to be removed by hand. The component page says the same in "How It Works". Tests: - New `EventbridgeConsumerUserQueueTargetTest` (4 tests). The mocked EventBridge client keeps the rule as a map of target id to ARN, with the semantics of PutTargets (replace by id) and RemoveTargets. Without the fix `twoConsumersSharingAQueueAddOneTarget` and `restartAfterACrashAddsNoSecondTarget` fail with `expected: <1> but was: <2>` (two `camel-eb-xxxxxxxx` targets for the queue), and `userQueueKeepsCollectingEventsWhileTheConsumerIsStopped` fails because the target was removed. `autoCreatedQueueTargetIsStillRemovedOnStop` passes with and without the fix; it shows that the auto-created path is unchanged. - `EventbridgeConsumerTest.testUserProvidedQueueNotDeletedOnShutdown` checked that the target of the user queue is removed on stop; it now checks that the target is kept and the queue is not deleted. - camel-aws2-eventbridge unit tests: 30 run, 0 failures (formatter and import sort run in the same build). - Not run: the LocalStack integration tests (they need Docker). The EventBridge semantics the tests rely on (every target of a rule receives the event; PutTargets with an existing id updates that target) come from the AWS API reference, not from a run against AWS. How it was found: a small TLA+ model of the targets of the rule (consumers sharing a user queue that start, stop or crash, and events put on the queue once per target) found a duplicate in 4 steps for two consumers and for one consumer that crashed and started again. With the fix, no duplicate and no lost event for 2 and 3 consumers. The tests above reproduce it on the real consumer. # 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 camel-aws2-eventbridge, including the formatter and import-sort plugins, and updated the catalog copy of the component page by hand. 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]
