Fix Http2 MultiConnection test race conditions #91156
Merged
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.
Closes #91075
These tests have logic along the lines of
When a new Http2 connection is being added to the pool, it will first check whether there are any pending requests on the queue. It will signal those requests before storing itself in the list of available connections on the pool.
When the warmup request in
SetupConnectionAsync
was woken up, it would be fully processed quickly. We would then continue to queue up new client requests assuming we already have a connection in the pool to handle them.However due to the race condition, the connection hasn't added itself to the pool yet, so these queued requests end up kicking off a new connection attempt.
You can then get into a situation where the next
SetupConnectionAsync
will receive a request, but it won't be the same request as the warmup task. Because the warmup task never got a response, the test would time out.This change fixes this race by making sure to accept all pending requests on the server first, before initiating a new connection. As all previous requests will be accepted already,
SetupConnectionAsync
will see the first request on the connection being the warmup one correctly.The issue happening with
Http2_MultipleConnectionsEnabled_IdleConnectionTimeoutExpired_ConnectionRemovedAndNewCreated
is a slight derivation of the above.We would also start an extra connection attempt, but as the test involves waiting 20 seconds for the connection to hit the pool idle timeout, that connection attempt would end up hitting
PendingConnectionTimeoutOnRequestCompletion
.When we went to accept a new connection after the fact, the loopback server would accept that already-cancelled connect attempt, and fail when trying to use that connection.
This change fixes that by blocking that third connection attempt from going through
ConnectCallback
to the socket layer until we're ready to accept it.