TestHostClientMaxConnWaitTimeoutError test case sometimes fails #1832
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.
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
test
due to theTestHostClientMaxConnWaitTimeoutError
test case.#1818
#1829
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.
This fix should resolve the issue.
The reason for the failure of this test case is related to the issue described in #1830.