Re-join channels on reconnect

[edevil]

As it stands, when there is a problem with the websocket it is automatically reconnected. However, the previously joined channels are not rejoined, and we don't seem to get any message that would allow the client to perform that task (although I think that the library should take care of this).

[igoodrich]

I just filed a related issue with elm-lang/websocket:
elm-lang/websocket#10

I think re-joining the channels on re-connect would be impossible given the current WebSocket.elm API. It's missing notification of re-connect. For the reasons outlined in the issue above, I think it's a general problem with the WebSocket module and not specific to phoenix at all.

Anyway, we'll see if anyone is willing to address. If not, I think the option is to copy WebSocket.elm and modify it notify of reconnects and republish as a separate package.

Also, I agree that this library should re-join channels on re-connect. At the very least, it needs to notify the clients of this library that a re-connect has happened so that they can tell the server who they are and catch up.

[igoodrich]

I just filed a related issue with elm-lang/websocket:
elm-lang/websocket#10

I think re-joining the channels on re-connect would be impossible given the current WebSocket.elm API. It's missing notification of re-connect. For the reasons outlined in the issue above, I think it's a general problem with the WebSocket module and not specific to phoenix at all.

Anyway, we'll see if anyone is willing to address. If not, I think the option is to copy WebSocket.elm and modify it notify of reconnects and republish as a separate package.

Also, I agree that this library should re-join channels on re-connect. At the very least, it needs to notify the clients of this library that a re-connect has happened so that they can tell the server who they are and catch up.

[Voronchuk]

I'm wondering can't the library re-join the channel, having unmatched topic in response reason?

Phoenix message: { event = "phx_reply", topic = "rooms:lobby", payload = { status = "error", response = { reason = "unmatched topic" } }, ref = Just 2119 }

[Voronchuk]

I'm wondering can't the library re-join the channel, having unmatched topic in response reason?

Phoenix message: { event = "phx_reply", topic = "rooms:lobby", payload = { status = "error", response = { reason = "unmatched topic" } }, ref = Just 2119 }

[igoodrich]

@Voronchuk I think the underlying elm websocket library auto re-connects in such a way that the elm-phoenix-socket library will never get that message and so can't respond to it.

[igoodrich]

@Voronchuk I think the underlying elm websocket library auto re-connects in such a way that the elm-phoenix-socket library will never get that message and so can't respond to it.

[Voronchuk]

@igoodrich so { socket | debug = True } this part simply delegates the debugging to elm websocket which actually renders those debug messages and we can't intercept those messages on elm-phoenix-socket level... makes sense.

[Voronchuk]

@igoodrich so { socket | debug = True } this part simply delegates the debugging to elm websocket which actually renders those debug messages and we can't intercept those messages on elm-phoenix-socket level... makes sense.

[alexspurling]

Could I ask, why does the websocket library issue a re-connect after 60s of inactivity?

[alexspurling]

Could I ask, why does the websocket library issue a re-connect after 60s of inactivity?

[CD1212]

Has anyone found a work around for this?

Phoenix.Channel.onClose or Phoenix.Channel.onError don't appear to be called after a websocket disconnects, so there doesn't appear to be a way to reconnect there. I am hitting the same unmatched topic error as others have mentioned.

[CD1212]

Has anyone found a work around for this?

Phoenix.Channel.onClose or Phoenix.Channel.onError don't appear to be called after a websocket disconnects, so there doesn't appear to be a way to reconnect there. I am hitting the same unmatched topic error as others have mentioned.

[djthread]

I am also very keen to solve this problem ... and the exponential backoff feature, too, seems pretty essential for a production app. Any developments on any of this out there?

Big-time kudos to @fbonetti and everyone contributing to this great library tying together a pair my very favorite tools!

[djthread]

I am also very keen to solve this problem ... and the exponential backoff feature, too, seems pretty essential for a production app. Any developments on any of this out there?

Big-time kudos to @fbonetti and everyone contributing to this great library tying together a pair my very favorite tools!

[maxstr]

@djthread, as noted above fixing this in a native Elm library isn't possible until the Elm WebSocket library is improved. It's unfortunately pretty bare bones right now. You may be interested in this effect manager though!

[maxstr]

@djthread, as noted above fixing this in a native Elm library isn't possible until the Elm WebSocket library is improved. It's unfortunately pretty bare bones right now. You may be interested in this effect manager though!