Replace task.Wait() with Await disposes HttpContext.Features of the current HttpRequest

[JuergenAuer]

Hi,

I have a crazy problem I don't really understand.

Background: Old web application, developed Net.Framework.1.1, startet 2006 2.0, later 4.0, two years 8.0, now 10.0, IIS In-Process hosted, Minimal Api.

The application uses 4 additional services, one is like a session service (replaced the Framework ASP NET State Service), one is something like a cache (but with Db-Checks), one creates pdf files, the latest is a routing calculation. (2)/(3) earlier with NET.Remoting. Now all 4 services are IIS In-Process hosted, Minimal Api, they consume a Xml-Document with the command and parameters and send a Xml-Document back. The client-code executed by the web application and the first part of the server-code of all 4 services is nearly the same, that calls the (sometimes 15 - 20 years old) functions.

Long time I didn't use async / await. Started the last years with the switch to NET.8. Later I found:

_task = _httpClient.PostAsync(...)
_task.Wait()

is bad, because it blocks the current thread. So I've started to recheck the whole code to find such .Wait( and to add async on the whole function stack.

But: Changed that row to

Using _httpResponseMessage As System.Net.Http.HttpResponseMessage = Await _httpClient.PostAsync(...)

results in an error later:

IFeatureCollection has been disposed.
Object name: 'Collection'.
at Microsoft.AspNetCore.Http.Features.FeatureReferences`1.ThrowContextDisposed()
   at Microsoft.AspNetCore.Http.Features.FeatureReferences`1.ContextDisposed()
   at Microsoft.AspNetCore.Http.Features.FeatureReferences`1.Fetch[TFeature](TFeature& cached, Func`2 factory)
   at Microsoft.AspNetCore.Http.DefaultHttpRequest.get_Cookies()

trying to read the number of cookies of the request. Rechecked the code, no missing Await found. The error happens in the client of the session service, trying to read the session. If the browser doesn't send a cookie, no crash.

Looks like using Await changes the thread and removes handles to HttpContext-Objects, so these objects are disposed.

But normally different calls of the same function should not affect the life span of other objects.

Additional observation: If I add a private variable this_CookieCollection to my main class and initialize it with HttpRequest.Cookies, that crash can be removed. But then follows the next crash with HttpRequest.QueryString and the same type of error message. It's not possible to fix that bug using the same idea.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[wfurt]

Moving to aspnet since the exception bubbles from there.

[martincostello]

This sounds like you're trying to use the HttpContext in a background thread after the current HTTP request has ended. That isn't supported as HttpContext instances are pooled, so the internals will be disposed at the end of the current request so they can be used to service a future request.

You should copy the information you need out of the active HttpContext (e.g. var cookies = httpContext.Request.Cookies;) before passing it to your asynchronous background task.

If you aren't intentionally doing background processing, then that points to a bug in your code that isn't awaiting the current HTTP request correctly.

If you think this is a bug in ASP.NET Core and what you're doing is correct and follows the guidance above, please provide a minimal reproducible example as a public GitHub repository (not a ZIP file, for instance) that someone could take a look at and debug.

[JuergenAuer]

Hi @martincostello

thanks sharing your ideas.

I found the own error. The initial function call was the problem (_wA is a WebApplication):

Original:

_wA.Map("/{**catchall}", Async Sub(catchall As String, hWebRequest As HttpRequest, _
HWebResponse As HttpResponse, context As HttpContext)
		Await route_Endpoints(hWebRequest, hWebResponse, context, _memCache, _wA)
	End Sub)

That worked, if the code is synchronous or if every async - call has a task.Wait().

But with a complete stack without .Wait() that ended the initial call.

Solution:

_wA.Map("/{**catchall}", Async Function(catchall As String, hWebRequest As HttpRequest, HWebResponse As HttpResponse, context As HttpContext)
		Return Await route_Endpoints(hWebRequest, hWebResponse, context, _memCache, _wA)
	End Function)

It's not an ASPNet-Problem. It's a problem rewriting an old application to use async / await.

Doing this bottom -> top there must be some task.Wait() calls to use an _Async-Function in an own synchronous method.

This were some first steps to change the code.

Later I've changed the initial call, it worked, but task.Wait() hides the problem.

Now there was a complete call without a task.Wait() - and the problem became visible.

The problem has nothing to do with the Session class.

To find the critical code, I've created a small async function and inserted a call in the main code (different positions).