How to deal with error "attempted to subscribe while channel is in Failed state"

[liuzhen2008]

We sometimes get this error when trying to attach to a channel.

"attempted to subscribe while channel is in Failed state"

In what kind of situation does this problem occur? It shows up in our crashlytics reports however we weren't able to reproduce the problem.

[ricardopereira]

@liuzhen2008 Thanks for opening an issue.

That's an old lib behaviour that shouldn't with v1.0. If the channel is in the Failed state, the attach should remove the error and proceed with the attach operation. Right @tcard? I'm looking at RTL4g.

[tcard]

@ricardopereira That's about attach, not subscribe. On subscribe, we have this, which we shouldn't have since there's no spec item requiring it.

I think the spec should be updated, since RTL7 is not really exhaustive. I think RTL7c should say "if the channel is not ATTACHING or ATTACHED". @mattheworiordan ?

[liuzhen2008]

So.. is there something I could do in the mean time so that it doesn't go to a "failed" state?

Or am i waiting for an update..

Or are you guys saying this will not happen with v1.0.9?

[mattheworiordan]

I think the spec should be updated, since RTL7 is not really exhaustive. I think RTL7c should say "if the channel is not ATTACHING or ATTACHED". @mattheworiordan ?

@tcard why does it need to do anything? The spec clearly states an implicit attach ONLY happens when in the Initialized state. So is the iOS lib trying to attach when already attaching? If so, why is that a problem. It's valid to call attach when attaching without expecting a failure.

@ricardopereira can you shed any light on this?

[ricardopereira]

Initially I thought it was something that we missed when we updated the lib to v1.0 but it's not. RTL4g or RTL7c didn't suffered any change from v0.8 to v1.0.

We sometimes get this error when trying to attach to a channel.

"attempted to subscribe while channel is in Failed state"

BTW, this error only happens when an subscribeWithAttachCallback: is being called:

https://github.com/ably/ably-ios/blob/3efd759737b4867bae8d82fbfe7fb7785cc622fd/Source/ARTRealtimePresence.m#L383-L386

So, I agree with @mattheworiordan. The spec is ok and clear.
Now, in this case, why shouldn't the attach run as normal when the channel state is Failed?

[tcard]

OK, never mind then. @ricardopereira I guess we should do what the spec says and only that, ie. check that the current state is INITIALIZED and only attach if it is. And of course do nothing special if FAILED, add the subscription and that's it.

[tcard]

@liuzhen2008 Sorry, we didn't really answer you. The FAILED state means that there's a bug somewhere, and it's irrecoverable; the only thing you can do is to connect again. From our docs:

An indefinite failure condition. This state is entered if a connection error has been received from the Ably service (such as an attempt to connect with invalid credentials). A failed state may also be triggered by the client library directly as a result of some local permanent error.

In the failed state, no reconnection attempts are made automatically by the library, and clients may not publish messages. A new connection attempt can be triggered by an explicit call to connect on the Connection object.

You should get insight into why it's happening by listening to .failed connection state changes and logging its reason field.