HttpClient async methods are blocking the first time

[IS4Code]

Description

Task-returning methods on HttpClient are blocking for up to a few seconds when called for the first time, despite their documentation:

This operation doesn't block.

Reproduction Steps

var stopwatch = Stopwatch.StartNew();
Log("Start");
var task = TestHttpClient();
Log("Waiting for result...");
var result = task.Result;
Log("Length: " + result.Length);

async Task<string> TestHttpClient()
{
    using var client = new HttpClient();
    Log("Sending request...");
    using var response = await client.GetAsync("http://example.org/");
    Log("Response received.");
    return await response.Content.ReadAsStringAsync();
}

void Log(string str)
{
    Console.WriteLine($"{stopwatch.Elapsed.TotalSeconds:0.00} {str}");
}

Expected behavior

Waiting for result... should be displayed shortly after Sending request... when the asynchronous operation starts.

Actual behavior

0.00 Start
0.07 Sending request...
6.64 Waiting for result...
6.96 Response received.
6.96 Length: 1256

Regression?

Also tested on .NET 6 and .NET Framework 4.8 with the same results.

Known Workarounds

Using Task.Run or loading HttpClient.DefaultProxy are the only options to get rid of the blocking.

Configuration

.NET 9.0.100

Other information

Debugging reveals that the blocking operation happens in HttpConnectionPoolManager, when HttpClient.DefaultProxy is requested.

Retrieving HttpClient.DefaultProxy eventually leads to WinHttpGetIEProxyConfigForCurrentUser where the majority of the blocking comes from (even if no system-wide proxy is configured). This operation is executed non-asynchronously, hence it blocks the construction of the Task.

[MihaZupan]

eventually leads to WinHttpGetIEProxyConfigForCurrentUser

Do you see this on multiple machines, or does it only reproduce on one?

Do you mind also trying the workaround mentioned in #30025 (comment) to see if that helps?

6 seconds is long, so I could see this impacting calling code (e.g. UI that becomes unresponsive for several seconds at startup).
Given it's only a problem during the first access to the property, I think it'd be fine to hide it behind Task.Run.

[IS4Code]

@MihaZupan Sorry for the delay. I have done some testing and so far on most other machines it seems the delay is much shorter, about 100 to 300 ms.

Thank you for the workaround ‒ this makes it behave the same as on the other machines. The delay is still there (and blocking), but not that noticeable.

[MihaZupan]

While definitely much better, it's still quite a bit, and of course not everyone can/will tweak those settings.
I'd be inclined to move the handler chain setup (or at least the initial proxy setup) after an async yield.

Is this something you'd be interested in contributing a change for?

Triage: Not critical for .NET 10 since it has been this way forever, but something we might be able to improve

[quixoticaxis]

I'd be inclined to move the handler chain setup (or at least the initial proxy setup) after an async yield.

Would it be appropriate to introduce conditional yield point?

HttpMessageHandlerStage handler = null!

if (_handler is null)
{
    await Task.Yield();
    // the only downside I see is that if someone
    // initializes thousands of method calls in a burst
    // workflow, the code would initialize thousands
    // of handlers to finally use the first to be ready
    // while the current version would block
    // and create only one
    handler = _handler ?? SetupHandlerChain();
}

And is it fine that the exception throwing behavior would change in this case?

[MihaZupan]

I'd flip the order so that ValidateAndNormalizeRequest is called first, then conditionally yield if the handler isn't set yet.

E.g.

Exception? error = ValidateAndNormalizeRequest(request);
if (error != null)
{
    return Task.FromException<HttpResponseMessage>(error);
}

return _handler is { } handler
    ? handler.SendAsync(request, cancellationToken)
    : CreateHandlerAndSendAsync(request, cancellationToken);

async CreateHandlerAndSendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
    await Task.CompletedTask.ConfigureAwait(ConfigureAwaitOptions.ForceYielding);
    HttpMessageHandlerStage handler = SetupHandlerChain();
    return await handler.SendAsync(request, cancellationToken);
}

the code would initialize thousands of handlers to finally use the first to be ready
while the current version would block and create only one

This is already possible if you send multiple requests in parallel, and isn't really an issue.
The expensive parts (connections) always use a single handler since that's what SetupHandlerChain ensures.

runtime/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/SocketsHttpHandler.cs

Lines 565 to 569 in 91195a7

	// Ensure a single handler is used for all requests.
	if (Interlocked.CompareExchange(ref _handler, handler, null) != null)
	{
	handler.Dispose();
	}

[quixoticaxis]

I'd flip the order so that ValidateAndNormalizeRequest is called first, then conditionally yield if the handler isn't set yet.

That's what my question was essentially about.

This is already possible if you send multiple requests in parallel, and isn't really an issue.

I was thinking more about scenario along the lines of await Task.WhenAll(lotsOfItems.Select(/* SendAsync */)) which would currently create only one handler, but if it is not an issue, then ok.

Ok, got it. I'll think about how to test it and probably send a PR.

[IS4Code]

I appreciate the use of Task.CompletedTask.ConfigureAwait(ConfigureAwaitOptions.ForceYielding) instead of Task.Yield ‒ the way I understand it, that should guarantee the continuation will run on the thread pool, and not on the UI thread, for example.

Is this something you'd be interested in contributing a change for?

I see you have arrived at a perfect solution already, so I don't need to take the authorship. 😁

[timcassell]

It might make sense to cache the Task and use it as an "async lazy" so that many threadpool threads won't be starved waiting for the setup (a bonus is you can ensure only a single handler is created).