azure-sdk-for-net: [BUG] Intermittent 'Authentication failed: Response was not set, make sure SendAsync' was called when authenticating

For what it’s worth, it looks like updating System.Diagnostics.DiagnosticSource to 6.0.0 may have resolved this for us. That version is compatible with both older .NET Framework and .NET Core projects and includes the change in dotnet/runtime I linked above to suppress exceptions thrown by inspected properties. It’s early still, so I can’t say it’s gone for good, but I was getting this exception regularly over the last few days and haven’t seen it since the package change.

Of course, that doesn’t mean the Azure SDK HttpMessage isn’t still throwing on inspection, just that the DiagnosticSource isn’t bubbling it up. Even with this “fix” I still think there’s something left to look at in the Azure SDK.

I’m running into a similar issue with .NET Framework 4.7.2 but Jetbrains Rider not Visual Studio (The same situation @fp-jcorriveau is in, other colleagues can use it fine in VS). Even if I start the process separately and attach Rider’s debugger it still throws the exception:

System.InvalidOperationException: Response was not set, make sure SendAsync was called
   at Azure.Core.HttpMessage.get_Response()
   at System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.PropertySpec.PropertyFetch.TypedFetchProperty`2.Fetch(Object obj)
   at System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.PropertySpec.Fetch(Object obj)
   at System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.Morph(Object obj)
   at System.Diagnostics.DiagnosticSourceEventSource.FilterAndTransform.Morph(Object args)
   at System.Diagnostics.DiagnosticSourceEventSource.FilterAndTransform.<>c__DisplayClass2_1.<.ctor>b__2(KeyValuePair`2 evnt)
   at System.Diagnostics.DiagnosticSourceEventSource.CallbackObserver`1.OnNext(T value)
   at System.Diagnostics.DiagnosticListener.Write(String name, Object value)
   at Azure.Core.Pipeline.DiagnosticScope.ActivityAdapter.Dispose()
   at Azure.Core.Pipeline.DiagnosticScope.Dispose()
   at Azure.Core.Pipeline.RequestActivityPolicy.<ProcessAsync>d__11.MoveNext()

Same error, same scenario

Updayting System.Diagnostics.DiagnosticSource to 6.0.0 seems to be the resolution here. The fix is here https://github.com/dotnet/runtime/pull/49567

We’re also seeing this across multiple developers using Rider:

Pretty sure this is happening because anything that reads properties for diagnostic purposes is going to end up triggering this exception when it does if it attempts to get diagnostics before the message is sent:

After lots of research, we may have narrowed this down to some of the Azure plugins attaching a DiagnosticSource in Rider, but it does seem to happen even when those are off. I’m not surprised it’s happening in Visual Studio too - it seems like this would be a general issue any time something has attached certain kinds of diagnostics, whatever host that may be. You can see the LoggingPolicy getting in the mix in the stack trace.

IMO having the HttpMessage throw like this in a getter seems like an anti-pattern. In general I think the guidance has always been to avoid throwing based on the state of the object inside a property whenever possible.

One possibly important data point is that we’re running on .NET Core 3.1 right now. It looks like the DiagnosticSource may have been changed to suppress these kinds of exceptions in properties in .NET 6 from the commit linked above: https://github.com/dotnet/runtime/pull/49567. I’m not in a position to update our runtime right now for this app, but I wonder if doing so would resolve the issue (or at least hide it), and if anyone reporting this problem is on >= .NET 6.

I’m running into a similar issue with .NET Framework 4.7.2 but Jetbrains Rider not Visual Studio (The same situation @fp-jcorriveau is in, other colleagues can use it fine in VS). Even if I start the process separately and attach Rider’s debugger it still throws the exception:

System.InvalidOperationException: Response was not set, make sure SendAsync was called
   at Azure.Core.HttpMessage.get_Response()
   at System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.PropertySpec.PropertyFetch.TypedFetchProperty`2.Fetch(Object obj)
   at System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.PropertySpec.Fetch(Object obj)
   at System.Diagnostics.DiagnosticSourceEventSource.TransformSpec.Morph(Object obj)
   at System.Diagnostics.DiagnosticSourceEventSource.FilterAndTransform.Morph(Object args)
   at System.Diagnostics.DiagnosticSourceEventSource.FilterAndTransform.<>c__DisplayClass2_1.<.ctor>b__2(KeyValuePair`2 evnt)
   at System.Diagnostics.DiagnosticSourceEventSource.CallbackObserver`1.OnNext(T value)
   at System.Diagnostics.DiagnosticListener.Write(String name, Object value)
   at Azure.Core.Pipeline.DiagnosticScope.ActivityAdapter.Dispose()
   at Azure.Core.Pipeline.DiagnosticScope.Dispose()
   at Azure.Core.Pipeline.RequestActivityPolicy.<ProcessAsync>d__11.MoveNext()

Yes, I can put something together. I also suspected project settings, given that it did not seem to be a commonly observed problem.