Of course, we don't need to guarantee that the return value of HostClient.connsWait.len() is zero when all client calls have exited, because this doesn't affect the correctness of the program in the same way as the HostClient.MaxConns field does.
There is a test in the suite, TestHostClientMaxConnWaitTimeoutError, which can cause the test to fail under certain conditions. We either need to remove this test or find a way to fix it. Additionally, false waiters could slightly impact the number of iterations in the loop during handle MaxConns semaphore in the HostClient.releaseConn method.
erikdubbelboer
commented
3 months ago
The current implementation makes some incorrect assumptions about observing changes in the state of wantConn.
The following two pull requests failed the GitHub workflow named
testdue to theTestHostClientMaxConnWaitTimeoutErrortest case. https://github.com/valyala/fasthttp/pull/1818 https://github.com/valyala/fasthttp/pull/1829Of course, we don't need to guarantee that the return value of HostClient.connsWait.len() is zero when all client calls have exited, because this doesn't affect the correctness of the program in the same way as the HostClient.MaxConns field does.
There is a test in the suite, TestHostClientMaxConnWaitTimeoutError, which can cause the test to fail under certain conditions. We either need to remove this test or find a way to fix it. Additionally, false waiters could slightly impact the number of iterations in the loop during handle MaxConns semaphore in the HostClient.releaseConn method.
This fix should resolve the issue. The reason for the failure of this test case is related to the issue described in https://github.com/valyala/fasthttp/issues/1830.