allthingssecurity opened a new pull request, #28463: URL: https://github.com/apache/camel/pull/28463
# Description [CAMEL-25945](https://issues.apache.org/jira/browse/CAMEL-25945) When an exchange completes, `QueueConsumer.processCommit` deletes its message. It reads the message id and pop receipt from the `CamelAzureStorageQueueMessageId` / `CamelAzureStorageQueuePopReceipt` headers as they are when the route ends. That goes wrong in two common cases: - The route forwards the message to another queue with an azure-storage-queue producer. `sendMessage` sets both headers to the id and pop receipt of the message it added to the target queue (`QueueOperationResponse.buildResponse` copies the `SendMessageResult` into them). The consumer then deletes that id from the source queue. Queue Storage answers 404 MessageNotFound, and the exception is logged as "ignored". - `removeHeaders("Camel*")` before calling another system. The delete throws `IllegalArgumentException: Message ID must be specified`. In both cases the received message stays in the source queue. It is consumed again after every visibility timeout until its time-to-live ends (7 days by default). In the forwarding case, every round puts one more copy into the target queue. Changes: - `QueueConsumer.processBatch` takes the id and pop receipt from the headers before the exchange is routed, and `processCommit` deletes that message through the consumer's `QueueClientWrapper`. - If the route updated the message (`operation=updateMessage`), the message gets a new pop receipt and the old one stops working. The header then has the same message id and the new receipt, so the header receipt is used. This keeps today's behaviour for that pattern. - The delete now uses the endpoint's `timeout` option instead of `CamelAzureStorageQueueTimeout`. That header belongs to a producer in the route. - The consumer no longer needs its `QueueOperations` instance. - No option, generated file or upgrade guide change: nothing for users to migrate. - History: CAMEL-16092 saved the received id, pop receipt and timeout and restored them before the delete. CAMEL-24158 (4.22) removed that restore so that the new pop receipt of an updated message is kept, and with it the protection against this override. This change keeps both cases working: the received message is deleted, and if the route updated that same message, its new receipt is used. - Backport: camel-4.23.x and 4.22.x have the same code as main. camel-4.18.x and 4.14.x still restore the received values, so forwarding works there, but an updated message is deleted with its stale receipt. A cherry-pick to those branches needs the restore removed as well. I read the code on those branches but did not run the tests there. Not covered: a route that first updates the message and then sends to another queue. In that case the header has the other message, and the receipt kept from the receive is stale. The delete fails with 400 PopReceiptMismatch, and the message comes back as it does today. Not changed (follow-up JIRA if wanted): `camel-aws2-sqs` deletes with the `CamelAwsSqsReceiptHandle` header in the same way. Its producer does not set that header, so only `removeHeaders("Camel*")` makes it miss. Tests: - New `QueueConsumerDeleteMessageTest` (JUnit assertions, as in the module). Its fake `QueueClient` answers like the Queue Storage REST API (comment on the fake): - Put Message returns the new id and pop receipt. - Update Message returns a new receipt and invalidates the old one. - Delete Message throws `QueueStorageException` with 404 MessageNotFound for an unknown id and 400 PopReceiptMismatch for a stale receipt. - Fail on main: - `forwardedMessageIsDeletedFromTheSourceQueue`: `Argument(s) are different! Wanted: deleteMessageWithResponse("a-1", "a-1-receipt-1", ...)`. The actual call was with `"b-1"`. - `messageIsDeletedWhenTheRouteRemovesTheCamelHeaders`: `Wanted but not invoked`. - `updatedMessageIsDeletedWithItsNewPopReceipt` is a control that passes on main and with the fix. - camel-azure-storage-queue unit tests: 14 run, 0 failures. The formatter and import-sort plugins ran. I built offline with `-Dasm-version=9.11` because asm 9.11.1 was not in my local repository. The ITs were not run locally; CI runs them. # 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): [CAMEL-25945](https://issues.apache.org/jira/browse/CAMEL-25945). # 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 camel-azure-storage-queue and ran its tests, including the formatter and import-sort plugins. No generated file changes. 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]
