I'm experiencing an issue that is hard/ugly to address with the current Socket implementation.

We have an application using phoenix channels, and we perform authentication on socket connection with a phoenix token. That is, we don't let the user join a channel if the provided token is expired or invalid.

This works well, and the server properly responds with a401 Unauthorized response. By using theerror_handler option for thePhoenix.Socket I can also include an error reason in the response body, and that works well too: the server is behaving correctly.

However, the js WebSocket client completely ignores that response, and produces aCloseEvent with code1006 and an empty reason. This is a well known issue, as explained here:https://stackoverflow.com/a/19305172. To make things worse, the very same close event is fired when the connection fails due to the server being down.

This means that if the connection was refused by the server, the js client will keep trying to reconnect indefinitely, polluting our logs and metrics with a lot of noise, and currently there's no way to stop it from reconnecting other than subclassing theSocket and relying on the class internals to change theonConnClose behavior.

For our use case, we want to know why the connection was refused to provide feedback to the user. The connection can be lost briefly during a deploy, or due to the user having the browser tab open longer than the token lifetime(this is super common for our users), and we want to provide different feedback depending on the case. We can figure out the reason without the event, we only need a way to stop the reconnections.

This PR adds a function that gives us a chance to stop the socket from reconnecting after a close event.

PS: if this is accepted, I'm wondering if it could be backported to phoenix 1.6