Crash in -[PTPusherChannelAuthorizationOperation finish] about libpusher

[lukeredpath]

Interesting. I can only assume what is happening here is that you are trying to unsubscribe from a channel on app resume or in some situation before the connection has been established?

libPusher supports subscribing prior to connection but I never really thought about unsubscribing before connecting. It's not a massive change but I might have to look at this tomorrow when I'm back at my desk.

[lukeredpath]

Just goes to show that assertions are useful for debugging though!

[soffes]

Haha for sure :)

Ya if it fails to connect and the user chooses something in my app, they will subscribe to a channel. If they nav back and choose another, it will unsubscribe from the first and subscribe from the second. Makes sense if they failed to connect.

[lukeredpath]

I have a hunch that trying to subscribe to a channel before connecting will result in the same error. The reason for this is, looking at the code that subscribes to a channel, it looks like I was relying on behaviour of the old socket backend (AsyncSocket) where trying to send data over the socket before it was connected would simply fail.

That meant I could blindly send the "subscribe" message over the socket and have it fail, and then simply loop through the channels and call "subscribe" again when the connection was established, causing them to subscribe if they hadn't subscribed already.

Because SocketRocket (correctly) asserts that sending data before connection is an exception, I think this will now crash.

Could you test this theory and try subscribing to a channel without connecting the Pusher client?

[lukeredpath]

I think the correct solution would be to tease out a better state machine for channels instead of having a boolean "subscribed" flag.

For instance:

Starts as: Unsubcribed

SUBSCRIBE: 
transition to: Waiting For Subscribe

if (connected) {
  // do subscribe
  transition to: Subscribed
}
else {
  // wait for connection
}

UNSUBSCRIBE
transition to: Waiting For Unsubscribe

if (connected) {
  // do unsubscribe
  transition to: Unsubscribed
}
else {
  // wait for connection
}

Then, in PTPusher (the connection delegate), when a connection is established:

foreach (channel that is in Waiting For Subscribe state) {
  [channel subscribe]
}
foreach (channel that is in Waiting For Unsubscribe state) {
  [channel unsubscribe]
  // remove channel 
}

[lukeredpath]

It may be worth having an additional state for private/presence channels such as Waiting For Authorization. I'll have a think about this.

[lukeredpath]

As you can see from my above commit, the more complicated state machine solution simply wasn't necessary. If the connection closes for some reason, for all intents and purposes you are unsubscribed from each channel (there isn't any need to send an unsubscribe message as well). We do mark channels as unsubscribed when disconnected, so the fix was to simply do nothing if you try and call unsubscribe on an already unsubscribed channel.

[soffes]

Perfect. Thanks!

[breezeight]

Hi @lukeredpath
I'm still seeing a similar bug with a nightly build of Jun 26 2012, see #67
I cannot manage to reproduce but it's happening to a lot of our users. Any idea?