Log exceptions thrown from HubProtocolReaderWriter methods

[AndriySvyryd]

These exceptions are quite common while configuring the protocol to serialize the data correctly and are hard to debug without adding catching code.

[moozzyk]

These exceptions are not handled in our code so should bubble up and should be automatically logged. Are you not seeing this? Can you show example/repro?

[moozzyk]

I think I just saw it with MessagePack where it failed to serialize an object of anonymous type due to:

Non-public type '<>f__AnonymousType0`2[System.String,System.String]' cannot be serialized.

AFAIR @BrennanConroy told me that they (MessagePack Cli) decided to throw for non public types.

[AndriySvyryd]

@moozzyk That's exactly what I see when I invoke something like this on the Hub:

public async Task<object> GetState() => new { state= "foo" };

It's not logged.

[AndriySvyryd]

Actually it does appear in the Debug provider, but without the message:
Exception thrown: 'System.NotSupportedException' in MsgPack.dll

However it doesn't appear at all in Console.

This is my config:

  "Logging": {
    "IncludeScopes": false,
    "Debug": {
      "LogLevel": {
        "Default": "Warning",
        "System": "Information",
        "Microsoft": "Information"
      }
    },
    "Console": {
      "LogLevel": {
        "Default": "Warning",
        "System": "Information",
        "Microsoft": "Information"
      }
    }
  }

[moozzyk]

@AndriySvyryd - Thanks for the details. I only got my message because I turned breaking on all exceptions. If this is MsgPack that catches it and turns into NotSupportedException without an error message we may not be able to do anything on our side. I will need to investigate to see what happens and maybe open an issue/send a PR to MsgPack to improve the experience/debugability if needed.

[AndriySvyryd]

@moozzyk I see the exception message correctly in Diagnostic Tools pane.

[moozzyk]

Need to dig more - searched quickly and I don't see any place where we throw the NotSupportedException without a message.

C:\source\SignalR-Core\src\Microsoft.AspNetCore.SignalR.Core\Internal\DefaultHubProtocolResolver.cs(29):                    throw new NotSupportedException($"The protocol '{protocolName ?? "(null)"}' is not supported.");
C:\source\SignalR-Core\src\Microsoft.AspNetCore.SignalR.Core\HubEndPoint.cs(276):                                        throw new NotSupportedException($"Received unsupported message: {hubMessage}");
C:\source\SignalR-Core\src\Microsoft.AspNetCore.SignalR.Core\HubEndPoint.cs(498):                    throw new NotSupportedException($"Duplicate definitions of '{methodName}'. Overloading is not supported.");

[AndriySvyryd]

When you get to this try throwing something from HubProtocolReaderWriter.WriteMessage

[moozzyk]

Will do.

[BrennanConroy]

Isn't this related to #861 and you only see the exception when the connection closes?

[AndriySvyryd]

@BrennanConroy Yes, this is the same.

[davidfowl]

@moozzyk is this an alpha2 candidate?

[moozzyk]

Possibly. I think that in this case the connection should be closed almost immediately due to the exception so you should see it soon after it is thrown. I am worried about the NotSupportedException exception without any details. Finally, I am worried about MessagePack not supporting serializing private types which is especially bad for anonymous types - I am planning to file an issue there and see what can be done about it.

[AndriySvyryd]

@moozzyk The NotSupportedException exception without any details was a bit of a red herring. It seems that's what shows up in the Debug output when it is thrown. Once it's caught all the details are logged correctly.
The connection not being closed might be the bigger issue here.

[moozzyk]

Thanks for the update!