Mediator breaks out of the logical CallContext

I’m having trouble with my mediator pipeline. I’m using the IRequestPostProcessor to implement both some workflow behavior and generic logging tasks.

Some of my mediator handlers are requesting the current user from HttpContext.Current.User, and for the most part, this works just fine. But lately we have experienced that the http context is not available.

I’m not 100% sure about this, but I think it’s a question of setting continueOnCapturedContext to false when calling next() in the RequestPostProcessorBehavior-implementation. At least, replacing the implementation with my own implementation that does not include the .ConfigureAwait(false) seems to solve the problem.

Is this a known problem? Is there a known solution?

(We’re still on MediatR 3.01)

[danielmarbach]

@jbogard yes. Since MediateR is a general purpose in-process messaging library I’d say ConfigureAwait(false) could be argued as a good default value. Especially considering that MediatR encourages you to have SRP handlers that can return responses and those responses can then be assigned to something like the ViewModel or the UI. With that design you should never need to access something that is context-aware inside a handler, thus ConfigureAwait(false) actually enforces that design decision.

[seesharper]

As long as we are in the world of System.Web, there is no guarantee that this will work anyway.

Stay away from ConfigureAwait(false) and you should be good.

By staying away I mean code that accesses the ambient context (eg HttpContent.Current )should not be asynchronously executed using ConfigureAwait(false)

.Net Framework 4.7.1 introduces the concept of Execution steps that seems to address this issue although I have never tested this myself. https://blogs.msdn.microsoft.com/dotnet/2017/09/13/net-framework-4-7-1-asp-net-and-configuration-features/