dotnet/aspnetcore

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

Open

#44,383 创建于 2022年10月5日

在 GitHub 查看
 (10 评论) (0 反应) (0 负责人)C# (10,653 fork)batch import
area-signalrhelp wanted

仓库指标

Star
 (37,933 star)
PR 合并指标
 (平均合并 16天 9小时) (30 天内合并 258 个 PR)

描述

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.

贡献者指南