When Socket connect failed

Phoenix Forum Questions / Help
1

Hi.

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
2

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

1 Like
3

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:

4

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).

5

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.

2 Likes