allthingssecurity opened a new pull request, #27854: URL: https://github.com/apache/camel/pull/27854
# Description [CAMEL-25600](https://issues.apache.org/jira/browse/CAMEL-25600) Follow-up of the review of #27761 ([CAMEL-25577](https://issues.apache.org/jira/browse/CAMEL-25577)). When the thread that waits for the answer of Telegram is interrupted, `TelegramMessageHandler` cancelled only the `thenApply` stage. Cancelling a dependent stage of a plain `CompletableFuture` does not cancel the future it depends on, so with a client whose `sendAsync` returns such a future the request was not given up. The handler now keeps the future that `sendAsync` returned and cancels it as well as the dependent stage. For the JDK `HttpClient` nothing changes in practice: its futures already pass the cancel of the `thenApply` stage on to the request. The new test shows this on the code of main too (the server sees the connection closed by the client after the interrupt). Tests: - New `TelegramProducerInterruptTest` (2 tests). Both check that the interrupted exchange is completed once, with a `RuntimeException` caused by the `InterruptedException`, and that the interrupt flag of the caller is kept. - `interruptCancelsTheFutureOfACustomClient`: a custom `client` whose `sendAsync` returns a plain `CompletableFuture` that never completes. Without the change it fails: `[future that sendAsync returned is cancelled] Expecting value to be true but was false`. - `interruptWhileWaitingForTheAnswerClosesTheConnection`: the JDK client against a local server that reads the request and never answers; the server sees the connection closed by the client. This test also passes without the change (see above); it is there so that the JDK case stays covered. - camel-telegram with the change: 113 tests, 0 failures, 1 skipped. Not changed: everything else on the send path, including the exception of the exchange on an interrupt. What was not run: only the camel-telegram tests, with JDK 21; no run against the Telegram service. That the JDK client aborts the request when the dependent stage is cancelled was seen with the JDK client of this build only. # 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-telegram, 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]
