dotnet/aspnetcore

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

Open

#44.383 geöffnet am 5. Okt. 2022

Auf GitHub ansehen
 (10 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)C# (10.653 Forks)batch import
area-signalrhelp wanted

Repository-Metriken

Stars
 (37.933 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 16T 9h) (258 gemergte PRs in 30 T)

Beschreibung

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.

Contributor Guide