Handle direct CanncelationException on timeout in JdkClientHttpRequest #34721
+136
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
spring-projects-issues
added
the
status: waiting-for-triage
giampa91
force-pushed
the
main
branch
2 times, most recently
from
1b96990 to
1717ef7
Compare
sbrannen
added
the
in: web
11 tasks
rstoyanchev
requested changes
Aug 1, 2025
spring-web/src/main/java/org/springframework/http/client/JdkClientHttpRequest.java
Show resolved
Hide resolved
| @@ -224,6 +228,7 @@ public ByteBuffer map(byte[] b, int off, int len) { | |||
| private static final class TimeoutHandler { | |||
|
|
|||
| private final CompletableFuture<Void> timeoutFuture; | |||
| private boolean isTimeout=false; | |||
There was a problem hiding this comment.
Likewise here, this flag is never used.
There was a problem hiding this comment.
sorry my mistake, now this variable has a purpose
…essException during timeout scenarios. Handle the CancellationExceptions in order to throw an ResourceAccessException when timeout occurred Closes spring-projectsgh-33973 Signed-off-by: giampaolo <[email protected]> fix: use timeoutHandler with a flag isTimeout Closes spring-projectsgh-33973 Signed-off-by: giampaolo <[email protected]>
|
Thank you for your patience @rstoyanchev ! After a careful review, I realized I hadn’t double-checked the code thoroughly enough. I’ve now updated the implementation to better distinguish between a cancelled request and a genuine timeout by explicitly checking the timeout variable. Additionally, I’ve added tests covering both scenarios. While there might still be room for optimization, I believe this approach reflects real-world usage and edge cases. |
rstoyanchev
added
type: bug
rstoyanchev
approved these changes
Aug 8, 2025
rstoyanchev
pushed a commit
that referenced
this pull request
Aug 8, 2025
Handle CancellationException in order to throw an HttpTimeoutException when the timeout handler caused the cancellation. See gh-34721 Signed-off-by: giampaolo <[email protected]> fix: use timeoutHandler with a flag isTimeout Closes gh-33973 Signed-off-by: giampaolo <[email protected]>
|
Fixed via 600d6c6 |
rstoyanchev
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CancellationExceptions are thrown instead of the expected ResourceAccessException during timeout scenarios.
Handle the CancellationExceptions in order to throw an ResourceAccessException when timeout occurred
Closes gh-33973