-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
P4
-
Affects Version/s: 26
-
Component/s: core-libs
The ConnectionFlowControlTest was introduced before the API that adds a HttpResponse.connectionLabel(), and relies on client TCP port numbers to detect whether a request was sent through a new connection.
As a result, it may intermittently and randomly fail if a port from a closed connection is immediately reused.
org.opentest4j.AssertionFailedError: expected: not equal but was: <localhost/127.0.0.1:37737->/127.0.0.1:48894>
at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:152)
at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertNotEquals.failEqual(AssertNotEquals.java:277)
at org.junit.jupiter.api.AssertNotEquals.assertNotEquals(AssertNotEquals.java:263)
at org.junit.jupiter.api.AssertNotEquals.assertNotEquals(AssertNotEquals.java:258)
at org.junit.jupiter.api.Assertions.assertNotEquals(Assertions.java:2819)
at ConnectionFlowControlTest.test(ConnectionFlowControlTest.java:210)
Using HttpResponse.connectionLabel instead of relying on the address tuple discovered on the server side to identify a connection would solve the issue.
As a result, it may intermittently and randomly fail if a port from a closed connection is immediately reused.
org.opentest4j.AssertionFailedError: expected: not equal but was: <localhost/127.0.0.1:37737->/127.0.0.1:48894>
at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:152)
at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertNotEquals.failEqual(AssertNotEquals.java:277)
at org.junit.jupiter.api.AssertNotEquals.assertNotEquals(AssertNotEquals.java:263)
at org.junit.jupiter.api.AssertNotEquals.assertNotEquals(AssertNotEquals.java:258)
at org.junit.jupiter.api.Assertions.assertNotEquals(Assertions.java:2819)
at ConnectionFlowControlTest.test(ConnectionFlowControlTest.java:210)
Using HttpResponse.connectionLabel instead of relying on the address tuple discovered on the server side to identify a connection would solve the issue.