When Socket connect failed


I am using phoenix to make a webapp. I found whether is network disconnected or server refused, the phoenix.js will always trigger the socket.onError hook.

So how to distinguish a connection failure is due to a server refusal or a network exception?

1 Like

I thought you could have the server send back an error reason? Could use that?

1 Like

I just stumbled on this myself. As far as I can see, the only possible return values from connect/2 of a socket are {:ok, socket} or :error. I would like to pass a reason to the phoenix.js client as well but it does not seem to be supported.

@OvermindDL1, how do you go about establishing a connection with your phoenix app and communicating back to the client what exactly was wrong with the connection parameters?

Any ideas would be very much appreciated :slight_smile:

I currently see only two options:

  1. use a “normal” endpoint to do the validation and let the client use that to get a token (or denial reasons on failure) and use that token for the socket connection
  2. use the socket anonymously and handle the validation part in-band within a channel

Both have the drawback of some added complexity on the client side (as compared to just being able to return a reason in connect/2 which currently is not possible as it seems).
I would like to have a websocket only solution but solution 1. does not allow this. Option 2 does allow that, but you loose a bit of grip on the socket connection I guess (as the id/1 function of a socket is basically useless and there is no easy way to terminate the connection from the server then).

Hi again,

After some digging around, it seems that the underlying websocket transport protocol does not support additional information to be sent alongside an upgrade request failure as @chrismccord also stated on the mailinglist. As mentioned there too, a suitable workaround can be to get the error afterwards by calling an additional endpoint (using the same parameters used for the socket connection) in order to figure out the error.

I could imagine, that it could be handled differently (by allowing the upgrade to proceed initially and calling the connect/2 function after that, using in-band error messages to the phoenix client in order to communicate the reason and then closing the connection). But I cannot judge how much of an impact this would have a - on the implementation server side and b - on the client and all code depending on the phoenix client implementation as semantics around the socket error and close callbacks would probably change.