StatusCodeException

[copumpkin]

My daemon was happily chugging along when I got a:

*** Exception: StatusCodeException (Status {statusCode = 403, statusMessage = "Forbidden"}) [("Date","Tue, 14 Jan 2014 11:10:00 GMT"),("Content-Type","text/javascript; charset=UTF-8"),("Transfer-Encoding","chunked"),("Connection","keep-alive"),("Cache-Control","no-cache, no-store, must-revalidate"),("Access-Control-Allow-Origin","*"),("Access-Control-Allow-Methods","GET"),("X-Response-Body-Start","{\"status\":403,\"service\":\"Access Manager\",\"error\":true,\"message\":\"Forbidden\",\"payload\":{\"channels\":[\"049f65dc-3af3-4ffd-85a5-aac102b2a579\"]}}\n")] (CJ {expose = []})

that killed it. I asked in #pubnub and it's apparently a status code the library should be handling.

[stephenlb]

SDK will always "Retry" forever until user calls unsubscribe().

subscribe() is truth for all time. the only thing which can undo a subscribe is an unsubscribe().

[tsloughter]

Thanks. And yup, easy enough, I'll add handling for that to retry and/or send it to onError callback.

[tsloughter]

Oh wait, was this on connect?

[copumpkin]

I had been connected for ages (hours or days) and at some point it gave me that and bombed out. I'm assuming one of the many behind-the-scenes HTTP requests got the 403.

[tsloughter]

Ok, yea, I realized after sending that that connect is also used to reconnect :). So probably still connect where it is erroring, since subscribe' always retries for an exception.

So I'll have to add that to connect/reconnect.

[geremyCohen]

@tsloughter the general pattern we're using in the other clients for PAM access denied handling is to send all 401 and 403 responses to the error callback.

From here, the developer is free to do whatever he wants based on the scenario at hand. (Insert a sleep, retry if foo, unsubscribe if bar, etc).

If you could implement that pattern, it would be excellent! :)

geremy

[stephenlb]

Geremy,

There is a know reason we can chat about that will block the stream. Always retry. There is a specific reason that I need to chat with you about at the office. Basically we need to retry always unless the user unsubscribes(). :smile:

[geremyCohen]

@stephenlb Ok, we'll chat in person about it.

[stephenlb]

A, correction: always retry on all errors, also fire error callbacks as Geremy describes and continue to retry forever until the user executes the unsubscribe() method.

Basically you are subscribed forever and the SDK continues to retry until the end of time or the user specifically unsubscribes().

Geremy correct me if I'm wrong but that's pretty much the jist of it?

[stephenlb]

Geremy, If my last comment is true, then my concern is of no consequence. :+1: We can still chat back at the office about specifics.

[stephenlb]

subscribe() is truth for all time. the only thing which can undo a subscribe is an unsubscribe().

[copumpkin]

Yeah, from a user perspective, the 403 means nothing to me, so I'd prefer not to have to handle it. If an error gives me a meaningful decision to have to make, then I should be able to make it, but it doesn't sound like this one does.

[stephenlb]

correcto. :)

[tsloughter]

Cool, I'll handle this over the weekend.

[stephenlb]

:+1: :smile:

[tsloughter]

I pushed a fix. But it still has some holes I haven't had time to deal with yet.

Right now it simply reconnects if it gets an exception that isn't a status code exception. If it is a status code exception it sends that to the error callback and then reconnects.

One question, should it simply continue on like there was no error (after calling the error callback) or reconnect? I wasn't sure if it could mean some bad state somewhere so better to just reconnect.

And is the disconnect callback only called on unsubscribe? Or should that be fired for some exceptions?

[tsloughter]

I'd like to get all this logic solid and correct before doing PAM, switching to the stream and looking at alternative interfaces to callbacks.

[stephenlb]

@tsloughter correct, continue onward as if there are no errors in all scenarios. And Ty for the patch!

• connect fires only once a subscribe() is successful
• all further connection states fire on disconnect and reconnect callbacks which may fire multiple times.
• disconnect fires when there is no route to PubNub (network is gone)
• reconnect fires when network is back.
• error fires all errors and problems.

[tsloughter]

I think it is pretty good now. @copumpkin agree? Can we close this issue?

[copumpkin]

Haven't had time to update my stuff to use it yet, and likely won't until the weekend. I'd just close it and I'll reopen it if it seems problematic :)