Confusion about Channel rejoin

[tonyarkles]

I saw #93 but don't entirely get what's going on here. If necessary I can try to put together a minimal PoC to demonstrate.

• I create a socket, create and join a channel on the socket, and then connect the socket.
• The server is currently down, so socket.onError and socket.onClose fire
• I bring the server up. socket.onOpen gets called, followed by Channel.rejoin. Have successfully rejoined.
• I bring the server back down. socket.onError and socket.onClose fire again multiple times
• I bring the server back up. socket.onOpen fires, but the channel does not rejoin.

Am I doing something wrong? #93 suggested that there might be a retry timer that I need to configure, but I didn't see anything in the example code/wiki about that. Help?

If I'm not doing something wrong and this is actually a bug, I'm more than happy to help nail it down and submit a PR.

[dsrees]

No i believe there is an existing bug in the channel rejoin process. I'm slowly in the process of making some changes to the library in which i've addressed this. If you could, could you point your dependency manager to use the 2.x branch and see if that works for you?

[tonyarkles]

I'll try it out right now!

[tonyarkles]

I'm going to have to play with this a bit more tomorrow when I'm less sleepy. There still seems to be something weird going on, although it could have to do with API changes in the new version as well. Two unfounded observations (that I'll verify):

• If I start the app while the server is down, it seems to connect the socket properly when the server comes back, but the channel doesn't appear to get joined.
• If I start the app while the server is up, it appeared to join the channel but then fired a "timeout" event on the channel even though it looks like a response was sent from the backend.

I'll make sure I'm not just losing my mind on these points tomorrow :). Happy to help dig!

[dsrees]

Thanks @tonyarkles. It would be helpful to know if you are using the default URLSessionTransport or the StarscreamTransport.

[tonyarkles]

@dsrees Looks like I'm using URLSessionTransport (default, I didn't change my socket creation code at all from the older version)

There's an interesting thing I'm chasing down this morning for a bit to hopefully find the source. If I start the app with the backend down and then start the backend, I get two join requests on the backend, with this nice message in between them:

[debug] Duplicate channel join for topic "user:xxxxxxx" in ChatServer.Web.UserSocket. Closing existing channel for new join.

I haven't yet figured out where that second request is happening inside the Swift app, but I feel like I'm getting closer.

[tonyarkles]

It looks like the original join push is getting saved, and then once the connection is established it:

• sends the original join request
• The Channel's self.socket?.delegateOnOpen callback triggers another join request

The original join request succeeds, the second one also succeeds, but the backend sends a "close" response back to the first join and that results in the Channel entering the closed state.

[dsrees]

@tonyarkles Thanks for digging. I think i figured out what might be wrong. I'll work on getting a fix

[dsrees]

@tonyarkles I've pushed an updated to 2.x. I've tested it out pretty well and not seeing the issue we've been talking about any longer. Can you give it a try in your project and make sure you're no longer seeing this behavior? Thanks!

[tonyarkles]

@dsrees I just noticed the email notification in my overflowing inbox. Apologies for not getting back to you sooner! I'll pull it down and try it out tonight!

[dsrees]

Closing this assuming its been resolved in 2.x. Feel free to comment back if you're having an issue still