Use a fresh execution context for application logic

[davidfowl]

Discard the execution context when running the user application in the http transport. This stops all async locals from flowing from the initial request that establishes the SignalR connection from flowing into the connection delegate pipeline.

• This officially breaks the IHttpContextAccessor in both blazor and SignalR applications (HttpContext will be null)
• The activity will no longer flow from the initial request into all SignalR invocations from that
• Logging scopes from the original request will not flow to application logic
• It breaks the current culture flowing from the request localization middleware

"Fixes" #29846. Blazor server will no longer get an activity.

cc @javiercn @SteveSandersonMS

[SteveSandersonMS]

It's a fairly aggressive change but does make sense to avoid the strangeness that HttpContext could be accessed in some hosting scenarios and not in others.

It will definitely break some apps, though hopefully not many. For such people, what's your opinion about having a compat flag to opt back into the old and unsupported behavior? I did a bit of searching for evidence about how widespread the breakage is likely to be, and:

1. The vast majority of discussion on the web about using IHttpContextAccessor in Blazor Server do specify clearly that you shouldn't or can't. It seems well understood. Our docs are fairly clear on this point.
2. However there are some posts that simply tell people to use IHttpContextAccessor without any caveats, e.g.:
   • https://www.syncfusion.com/faq/blazor/tips-and-tricks/how-do-you-use-the-httpcontext-object-in-blazor-server-side-to-retrieve-information-about-the-user-or-user-agent
   • https://medium.com/it-dead-inside/accessing-the-asp-net-core-base-url-so-many-ways-f07f6ee58f68

I guess the biggest issue would be if it turns out that some widely-used open-source or component-vendor component is using this, and hence it breaks apps that don't even have the power to change the component implementation. But it seems fairly unlikely since, at the very least, any such component would already not support WebAssembly, and would have to tell people to call builder.Services.AddHttpContextAccessor().

A further point in favor is that this is going in an early preview release, not in some RC or patch, giving plenty of opportunity to change course later if needed.

So altogether I'm comfortable with the breaking change. We'd still need to make the announcement and write up the steps to work around it (e.g., if people were doing this to access some cookie data, they should read it in _Host.cshtml and pass the data in as a root component parameter).

[SteveSandersonMS]

Blazor server will no longer get an activity.

What impact does this have on default tracing behavior? Does it mean that things that were traced before are no longer traced, or they are just grouped differently? Is the new default better than the old one?

[javiercn]

@davidfowl I concur with what @SteveSandersonMS has said here.

I am also supportive of this change, and I think it is best if we do it early to give libraries time to adapt if needed.

I think we should think about what uses people typically have for HttpContext within Blazor apps and see if we can smooth out the pattern to deal with those.

I do not think we have concrete docs about how to do this properly, outside a comment about how to do it for passing the auth tokens to the circuit in Blazor Server apps.

I'm also in favor if we want to have a compat switch to avoid surprises, but with the idea that it will last for a single release.

As for the tracing, we should ensure we do the work to produce the right experience for Blazor apps.

[davidfowl]

It’s breaking the blazor server tests that verify the current culture flows as well. That will definitely break some people.

the other option is to try to make the things that are broken “work. So potentially resetting the activity, and updating the http context accessor appropriately.

[DamianEdwards]

It’s breaking the blazor server tests that verify the current culture flows as well. That will definitely break some people.

@davidfowl did you have a proposal for how to preserve the culture from the original request? That seems important. Does it need a new Blazor abstraction to enable flowing it from the host (similar to AuthenticationStateProvider)?

[kaypee90]

I guess you meant Should we also create an activity here