The fundamental issue here is that the WCF design around OperationContext is broken: You can stack contexts through the use of OperationContext.Current, but there is no way to navigate from the child context back to the parent.
The workaround uses CallContext to track the original OperationContext if the service code fails to dispose the OperationContextScope and we end up with OperationContext.Current returning the wrong value.
Not sure if using ThreadLocal<T> coupled with an AsyncLocal<T> here would be better than using CallContext in this case. Reluctant to have to mirror the jumps that WCF OperationContext.Current does.
Make the
WcfOperationContextmore robust with explicit checks to prevent creating a context on a WCF client-sideOperationContextinstance.Also add a workaround for issue https://github.com/Microsoft/ApplicationInsights-SDK-Labs/issues/45.
The fundamental issue here is that the WCF design around
OperationContextis broken: You can stack contexts through the use ofOperationContext.Current, but there is no way to navigate from the child context back to the parent.The workaround uses
CallContextto track the originalOperationContextif the service code fails to dispose theOperationContextScopeand we end up withOperationContext.Currentreturning the wrong value.Not sure if using
ThreadLocal<T>coupled with anAsyncLocal<T>here would be better than usingCallContextin this case. Reluctant to have to mirror the jumps that WCFOperationContext.Currentdoes.