SignalR Client HubConnection.Start() throws exception and doesn't keep trying to connect like the documentation says it should

Question

When I call HubConnection.Start() to an endpoint that ISN'T UP AND RUNNING YET, I would expect that the HubConnection would do whatever it is that it's supposed to do to continually make the connection. At least I think that's what the SignalR client guide tells me:

When you call the Start method in a SignalR client, you are providing SignalR client code with all the information it needs in order to establish a physical connection to a server. SignalR client code uses this information to make an HTTP request and establish a physical connection that uses one of the four transport methods. If the transport connection fails or the server fails, the SignalR connection doesn't go away immediately because the client still has the information it needs to automatically re-establish a new transport connection to the same SignalR URL. In this scenario, no intervention from the user application is involved, and when the SignalR client code establishes a new transport connection, it does not start a new SignalR connection. The continuity of the SignalR connection is reflected in the fact that the connection ID, which is created when you call the Start method, does not change.

However, I am not seeing this. The Start() throws an exception. Even if I ignore it, and then bring my server hub up, the HubConnection doesn't attempt at all to connect again.

Am I misunderstanding the guide? Must I initially have to successfully connect FIRST before all of the SignalR Client reconnection logic takes place?

Answer 1

You must make the initial connection first.

According to David Fowl

...if the connection failed to start in the first place then it won't auto reconnect.

He also states this is done...

Because it's a more natual API. If you connect to a service that is down chances are something is really wrong. If you were connected at some point and the connection dropped , signalr will retry for a little bit then give up and disconnect. They are very different scenarios and we try to keep the connection up if there's blips in the network but not when failing to start the connection altogether. That behavior is more predictable.

Here is the link to the github issue

Also, here is a really awesome SO post that details a bunch of different disconnect scenarios

Answer 2

I think you might be confusing two different things - starting the connection with transport fallback and reconnecting. If you don't explicitly say what transport you want to use the SignalR client will try to connect using all the available transports (websockets, server sent events, long polling and forever frame (JS client)). If starting a connection with a given transport fails the client will try to use the next transport from the list using the same data (url, cookies etc.) it used for the previous transport. In that sense user intervention is not needed to try a different transport. However if starting the connection with the last transport fails the client will give up and throw and exception. In other words - the client will not re-try starting a connection with a transport that already failed when doing so.

After the connection has been started successfully the client will try reconnecting if the connection has been lost. In this case it will use the same transport it originally connected to the server with and will not try using other transports. If the client cannot reconnect to the server using this transport in a certain amount of time the connection will be closed.