SignalR client library needs better logging/access to underlying message data

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I made a silly mistake today that took me some time to debug because there appears to be no easy way to access the underlying messages sent by SignalR as plaintext.

I have a method where I added a cancellationTokenSource as such.

using (var cancelToken = new CancellationTokenSource(timeoutMS))
{
     return clientProxy.InvokeAsync<T>(methodName, request, cancelToken);
}

You might already be able to spot the problem (cancelToken should be cancelToken.Token) I had forgotten about this simple change I made and suddenly started getting the error:

Error reading JSON. ‘{’ is invalid after a value. Expected either ‘,’, ‘}’, or ‘]’. LineNumber: 0 | BytePositionInLine: 98.

I tried to enable detailed logging by adding trace for logging messages.

var conn = new HubConnectionBuilder()
.ConfigureLogging(logging =>
{
    logging.SetMinimumLevel(LogLevel.Trace);
});

Yet unfortunately I received no further details other than the message above.

In the end I needed to implement my own custom IHubProtocol by duplicating JsonHubProtocol which finally revealed the real error to me which was:

{"type":1,"invocationId":"9","target":"blahblah","arguments":[{blahblah}{"type":7,"error":"Connection closed with an error. NotSupportedException: Serialization and deserialization of 'System.IntPtr' instances are not supported. Path: $.Token.WaitHandle.Handle.","allowReconnect":true}

Describe the solution you’d like

I believe inside JsonHubProtocol -> ParseMessage on the error condition the entire message payload should be shown to the user or at least if tracing is turned on this should be the behaviour.

It should not be this difficult to find out what happened to cause deserialisation to fail.

Additional context

In summary, there should be more information when an error condition occurs deep inside the protocol.

[rafikiassumani-msft]

Triage: We should do the same thing we do in the JS client and log the raw messages.

https://github.com/dotnet/aspnetcore/blob/c647f58bd0e53ec5cd13bdec037ac53c444abf99/src/SignalR/clients/ts/signalr/src/IHttpConnectionOptions.ts#L39 https://github.com/dotnet/aspnetcore/blob/c647f58bd0e53ec5cd13bdec037ac53c444abf99/src/SignalR/clients/ts/signalr/src/Utils.ts#L61

[BrennanConroy]

Looking at this more closely, you’re hitting the issue described in https://github.com/dotnet/aspnetcore/issues/13651#issuecomment-527625710. As noted in the comment, there is a log on the server side that will have the nicer Json error message (it’s Error level now) that would have pointed you to the issue.