-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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.
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
Sockets do not reconnect after a short network disconnection #3161
Comments
Can you provide steps to reproduce this? I cannot reproduce on 1.4.0. Please also verify you are running updated phoenix.js, you can |
With respect to the 1000 close code, we intentionally don't reconnect if the server tells us it's ending the connection on purpose. How are you triggering your network disconnects? |
@in19farkt how on earth did you actually get Chrome dev tools offline mode to work for WebSocket connections? The only way I have been able to test this is by turning off my wifi. Issue I'm referring to: More on topic, I am experiencing the same issue after upgrading to Phoenix 1.4 and I'm actually experiencing this on longer disconnects. I'll update this with more information as I debug. |
We're running into similar issues. For me I can get it to disconnect (and not reconnect) just by locking my computer and letting it sit for a while. I was digging into this and noticed that we don't reconnect for sendHeartbeat(){ if(!this.isConnected()){ return }
if(this.pendingHeartbeatRef){
this.pendingHeartbeatRef = null
if (this.hasLogger()) this.log("transport", "heartbeat timeout. Attempting to re-establish connection")
this.conn.close(WS_CLOSE_NORMAL, "hearbeat timeout")
return
}
this.pendingHeartbeatRef = this.makeRef()
this.push({topic: "phoenix", event: "heartbeat", payload: {}, ref: this.pendingHeartbeatRef})
} Here it's saying that it will attempt to re-establish the connection, but we send Though in my case I'm not actually even seeing the heartbeat log. So I don't know if this has anything to do with heartbeats or not. It also should be noted that if I kill my server and then turn it back on, everything works great. Also, we have a script that loads and connects to a different phoenix app, and it's running 1.3 (which was before we stopped reconnecting on |
We are experiencing similar behaviour. When I cut off internet for just a second, the socket is closed and does not try to reconnect, i.e the onOpen callback is never triggered. But when I cut off internet for a longer period of time and the timeout is triggered, it does reconnect and everything works just fine. |
* phx/master: (26 commits) Support any struct with :endpoint key in helpers Inspect body in ConnTest.response/2 (phoenixframework#3267) update snippet to agree with latest phx.new (phoenixframework#3277) Only enable trim for HTML templates Revert reconnect optimizations which introduced regressions. Fixes phoenixframework#3161 (phoenixframework#3272) Reword sentence in Controllers guide (phoenixframework#3270) update documentation to reflect on function deprecations (phoenixframework#3269) Fix warning in presence Default log for render errors info should be debug Add jason to umbrella ecto deps. Fixes phoenixframework#3263 Add Elixir Slack community in the help column of the initial default page (phoenixframework#3262) Update heroku.md (phoenixframework#3241) add JavaPhoenixClient in 3rd party channels client libraries list (phoenixframework#3256) fix typespec for put_layout (phoenixframework#3253) Add version to umbrellas (mirror Elixir master) Fix references in guides (phoenixframework#3251) Add $PORT bind step in Heroku deployment guide (phoenixframework#3235) update link to mime types (phoenixframework#3249) Add Elixir 1.7 and 1.8 to Travis CI build matrix (phoenixframework#3248) Update learning.md (phoenixframework#3247) ...
This still happens sometimes. Not sure what the difference is in this case versus the first, as the fix that was introduced really helped. It seems like the socket will close itself, intentionally, if one of the heartbeats it tried to send isn't responded to properly. This results in the socket's onClose being called, and it will not reconnect again. The channels, however, are still there and they still try to reconnect. This confusion comes from the fact that they use the same |
Can you open an issue with steps to reproduce? As a sanity check, please also ensure you are on 1.4.2 js client, and you have |
@simpers I was able to recreate the issue and it has been fixed on master. Please give it a shot and lmk if all is green on your end. Thanks! |
Everything seems to work perfectly now, as far as I can tell :) Super thanks for the quick help, @chrismccord ! 👍 🎉 |
Hey, we're seeing similar behavior after upgrading to Phoenix JS 1.5.1. Environment: Actual Behaviour:
Expected Behaviour Steps to reproduce:
|
@themitigater Is it possible to reproduce in an example app you can push and share? That would help us debug easily. |
Environment
Expected behavior
Sockets try to reconnect after short network disconnection (5-10 seconds).
Actual behavior
Sockets remain disabled
Debug results
onConnClose
is called withevent.code === 1000
sothis.reconnectTimer.scheduleTimeout
is not be calledThe text was updated successfully, but these errors were encountered: