dotnet / dotnet/aspnetcore

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

Open
#44,383 10 comments 0 reactions 0 assignees View on GitHub
area-signalr help wanted
Dominant language
C#
Stars
38.4k
Forks
10.9k
Avg merge
2d 6h
Merged PRs (30d)
290

Description

### Is there an existing issue for this?

- [X] 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(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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.