From 3c87295976c98df6d6b0fda9101374a9b3a4ac84 Mon Sep 17 00:00:00 2001 From: Ryan Schmitt Date: Thu, 19 Jun 2025 08:25:30 -0700 Subject: [PATCH] TestSocketTimeout: Increase upper bound assertion for actual delay These test cases are intermittently failing in the build environment on macos-latest using JDK11, because some of the calls seem to be taking slightly more than twice as long as they ought to before timing out. I'm not able to reproduce the issue, but it's safe to increase the upper bound: we'll still know if one of the socket timeout config options stops working, since the `assertThrows` assertion will fail. --- .../org/apache/hc/client5/testing/sync/TestSocketTimeout.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/httpclient5-testing/src/test/java/org/apache/hc/client5/testing/sync/TestSocketTimeout.java b/httpclient5-testing/src/test/java/org/apache/hc/client5/testing/sync/TestSocketTimeout.java index 2c8194231f..49486c6b4d 100644 --- a/httpclient5-testing/src/test/java/org/apache/hc/client5/testing/sync/TestSocketTimeout.java +++ b/httpclient5-testing/src/test/java/org/apache/hc/client5/testing/sync/TestSocketTimeout.java @@ -112,7 +112,7 @@ void testReadTimeouts(final String param) throws Exception { assertTrue(actualDelayMs > expectedDelayMs / 2, format("Socket read timed out too soon (only %,d out of %,d ms)", actualDelayMs, expectedDelayMs)); - assertTrue(actualDelayMs < expectedDelayMs * 2, + assertTrue(actualDelayMs < expectedDelayMs * 3, format("Socket read timed out too late (%,d out of %,d ms)", actualDelayMs, expectedDelayMs)); } }