Why is AsyncLocal<HttpContextHolder> static?

[czb182]

aspnetcore/src/Http/Http/src/HttpContextAccessor.cs

Line 13 in 8efcca4

private static AsyncLocal<HttpContextHolder> _httpContextCurrent = new AsyncLocal<HttpContextHolder>();

It looks like HttpContextAccessor is registered as Singleton via helper method, so couldn't the AsyncLocal be non static, and would be basically the same? I'm trying to understand why we are setting a certain lifetime via static keyword, when we can set via DI as singleton.

Thinking further, if it were not static, couldnt it just be scoped? Would the context only need to be preserved across the request, not the lifetime of the app?

[Tratcher]

It looks like HttpContextAccessor is registered as Singleton via helper method, so couldn't the AsyncLocal be non static, and would be basically the same?

Yes, but we've had issues with people registering it themselves not as a singleton. It turns out there's no reason to have it not be static.

Thinking further, if it were not static, couldnt it just be scoped? Would the context only need to be preserved across the request, not the lifetime of the app?

We've considered an alternate service that was scoped and didn't use async locals at all. It would be simpler and less error prone. Unfortunately people need access to the accessor service from other singleton services where you can't inject scoped services.

[czb182]

Thanks, that makes sense. I hadn't thought about it not needing to be AsyncLocal if could always reference Scoped instance, and I see issue about resolving in Singleton instance.

While its on my mind, do you know more about why the object indirection is needed, as in comments? Why put the HttpContext inside another class, instead of having AsyncLocal? Is it just something special about HttpContext needed to be nulled out before overwriting, or is there a more generic issue?

[Tratcher]

It helps null it out at the end of the request pipeline, even if the async local is accidentally captured on a background thread execution context.

[davidfowl]

AsyncLocals are copy by value so setting it to null won't null out the references that were captured by user code. The indirection makes that problem go away as we just null out the HttpContext on the holder.

[PMExtra]

@davidfowl I can't understand why this holder can solve that problem. The user code will never capture the holder, but the HttpContext. Just nulling out the HttpContext on the holder still won't null out the HttpContext references, either.

[davidfowl]

I wrote about how async local works and how best to use it.

https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md#asynclocalt