Crash if the server is unreachable about libpusher

[lukeredpath]

No, I'd expect the auth request failure to bubble up to the delegate instead. Looks like I'm not checking for failure before trying to parse the auth response.

[soffes]

This is happening a decent amount in a beta build of one of my apps since I'm using Heroku with only one Dyno and it's timing out. I would really appreciate a fix :)

[lukeredpath]

I think this should be enough to fix the issue; it looks like the appropriate delegate method will be called if the auth operation fails (the underlying connection error will be available in the NSError passed to the delegate method in the userInfo, with the NSUnderlyingErrorKey).

I think the only problem was the attempt to try and parse the response data when the response was not successful, resulting in the crash you were getting.

I'll trigger a new nightly build for you to download and try.

[soffes]

Thanks man! I'll test and verify as soon as you post it.

[soffes]

Works great. Thanks!

[s5]

I'm getting this crash on the nightly build and in 1.4.

[lukeredpath]

Hi, are you able to provide a backtrace?

[s5]

It's identical to what the original poster provided above. Do you need any additional information?

On Wednesday, October 3, 2012 at 4:52 AM, Luke Redpath wrote:

Hi, are you able to provide a backtrace?

—
Reply to this email directly or view it on GitHub (#44 (comment)).

[s5]

Okay, I was finally able to build libPusher from source (whew!), and I added this quick fix to PTPusherChannelAuthorizationOperation.m

  if (responseData) {
      authorizationData = [[PTJSON JSONParser] objectFromJSONData:responseData];
  } else {
      authorizationData = nil;
  }

Without regard for matching your coding style or any other aspect of your code's logic (need to push an emergency update to the app store). Let me know if you'd like me to commit this fix.

The conditions are trying to authorize a private channel when the server is completely off and not even listening for connections.

[lukeredpath]

Thanks for this. If it works, please use it for our app. I will have a look at this tomorrow. The fix looks good, I'd just like to try and get a failing test case too. I plan to release a 1.4.1 release shortly so this will make it in.

[s5]

Great. Should I be attempting to push this over to you (getting 403 errors)?

[lukeredpath]

No need, thanks.

Sent from my iPad

On 3 Oct 2012, at 22:39, s5 [email protected] wrote:

Great. Should I be attempting to push this over to you (getting 403 errors)?

—
Reply to this email directly or view it on GitHub.

[teameh]

I got the same error using the latest lib, is this not commited yet?

[lukeredpath]

For those having a problem with this, can you please try the latest HEAD (nightly build will be available tonight).

[jeffblake]

This issue is still present. Hard to reproduce, but happens every so often for our clients