SendAsync was using InvokeCoreAsync code to send messages. In case of exception InvokeCoreAsync is blocking and returns a task to the user so they can await for the remote call to complete. Any exception thrown is caught and used to fail the task returned to the user. SendAsync does not return a special task to the user so re-using InvokeCore resulted in swallowing exceptions. While SendAsync is fire and forget it actually should throw if the message could not be send and it was not happening.
While adding tests it turned out we did not test cases where Invoke/SendAsync/StreamAsync were invoked before starting the connection and this resulted in a NullReferenceException. I also fixed that.
When the client cancels a streaming method the server would send an error completion. This was not correct because cancellation is not an error. We did not see this because our client ignores any messages for a given streaming invocation after sending a CancelInvokationMessage but other clients may want to drain messages before considering a streaming method canceled.
Late parameter binding
Storing exception thrown during parameter binding and rethrowing when the method is about to throw. This allows completing invocations with a HubException and keeping the connection open.
We will also no longer close the connection if parameters for client side methods cannot be bound. We will log and continue.
Fixes: #818
(Also fixing #1005 because I was just touching this line)
* fix issue with incorrect user detection when Invoking for User
* fix failed testcases
* use proper extension method to avoid potential null reference exception
* fix for channel name in redis version + follow SignalR team recommendations
* remove unncessary freespace
* remove whitespaces
* introduce IUserIdProvider to resolve user id
* Move IUserIdProvider from HubLifetimeManager to HubConnectionContext
* setting user id to connection context in hubendpoint
* Remove the params argument from IClientProxy
- This allows passing arrays without having to explicitly ToArray() or AsEnumerable()
- Added overloads up to 10 arguments
- Added tests
* Initial support for websocket subprotocols
- Exposes a SubProtocol property on WebSocketOptions that picks the
protocol for all connections on the end point.
- This is required for things like mqtt over websockets (the SubProtocol in
this case is something like mqtt or mqttv3.1)
- Added test
#402
We need to close the connection if there is an exception when writing to the transport on the server side. Currently if an exception happens it leaves the connection in an unsable state - after the exception no messages from the server will be sent to the client because the writing loop is terminated. Ignoring the message could cause hangs on the client side since we can fail while writing a completion message. In this case if the client is awaiting the invocation it will hang because the task will never be completed.
* Turned Stream into StreamAsync
- Before we were fire and forgetting the invocation that initiated
the streaming, this changes that so that the caller now has to await
to get the channel.
#899
* Added Cancellation support
- Added ConnectionAbortedToken to the HubConnectionContext. This allows
arbitrary code to access a handle that represents the connection lifetime
without handling OnDisconnectedAsync on the hub itself.
- Expose Abort on HubConnectionContext to allow server side methods to
abort the connection.
- Use the Abort to stop the main loop when unexpected invocation errors happen.
- Use the connection aborted token as unsubscribe from the IObservable and to complete
the IAsyncEnumerator for streaming results.
- Removed ConnectionFactoryDelegate and used Func<IConnection>
- Changed WithLogger that accepts ILoggerFactory to WithLoggerFactory
- Made UseLogger configure the existing ILoggerFactory or create a LoggerFactory
- Add support for setting the log level for console logs
- Updated tests
BrennanConroy
Pawel Kadluczka
Mikael Mengistu
Pawel Kadluczka
Nate McMaster
ivankarpey
David Fowler
moozzyk
FTWinston