8000 Add `shouldReconnectAfterClose` to js Socket by doorgan · Pull Request #5155 · phoenixframework/phoenix · GitHub
[go: up one dir, main page]
Skip to content

Add shouldReconnectAfterClose to js Socket #5155

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
doorgan wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add shouldReconnectAfterClose to js Socket #5155

doorgan wants to merge 1 commit into from

Conversation

@doorgan
Copy link
@doorgan doorgan commented Dec 6, 2022

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 a 401 Unauthorized response. By using the error_handler option for the Phoenix.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 a CloseEvent with code 1006 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 the Socket and relying on the class internals to change the onConnClose 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@doorgan
0