aspnetcore: Consider adding an error event handler for HubConnection

This looks like a good issue to tackle. We need to figure out the scope, is it client or server or both. What types of errors are customers trying to handle. The main thing here seems to be malformed payloads that stop us from invoking your method. Assuming it’s just the payload and not the outer framing, it should be possible on both server and client to have an error handler that gets called if dispatch fails altogether. It won’t be called if an exception is thrown after dispatch, this is strictly when we can’t never call your handler.

We also need to decide if we log when the unhandled error method gets called. Maybe we skip it assuming you might be doing logging in there an therefore it’s handled.

@BrennanConroy @AndersMalmgren There should be an Action<ErrorInfo> for general parse failures, and then if feasible, a separate one for each type matching the On<T> handler.

When the client or server sends a message, the intent is a change of program state on the other side. In a simple case, it’s add a line to a chat room. In a more complicated case, it’s some transaction impacting a data element in persistent storage. In any case, the intent was to change state on the other side of the wire - not to have the message ignored. But the outcome is that the message was ignored.

This potentially impacts every subsequent state change for the lifespan of the process, which is probably a bad thing. And so there should be a notification, to the process, “hey this didn’t work.” It’s an error case, so there shouldn’t be any impact to whatever throughput requirements you have.

In particular, client side, with MVVM - if the updates are intended to change the View Model, you have UI elements in an inconsistent state and that is… we’ll call it bad.

Server side, client told you to change some row in some database and the row never changed. But you didn’t get back a success or a failure message, since the server just ignored your request.

I’d think there’s never an outcome from having a notification method available that is worse than not having a notification available.