2

I am posting a request and checking for errors like so:

// Send request out on a background thread
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
    [postRequest performRequestWithHandler:^(NSData *responseData, NSHTTPURLResponse *urlResponse, NSError *error) {
        if ([urlResponse statusCode] == 200) {
            NSLog(@"Tweet Successful");
        }else {
            NSLog(@"Tweet Failed");
            if (responseData) {
                //  Use the NSJSONSerialization class to parse the returned JSON
                NSError *jsonError;
                NSArray *requestResponse =
                [NSJSONSerialization JSONObjectWithData:responseData
                                                options:NSJSONReadingMutableLeaves
                                                  error:&jsonError];

                if (requestResponse) {
                    NSLog(@"%@",requestResponse);
                } else {
                    NSLog(@"%@",jsonError);
                }
            }
        }
    }];
});

It seems to work fine, so far as the request is concerned. My intention was to queue the request on failure and try again at a later date, or not depending on the error and how many attempts had failed thus far. The problem I have is that I find it frequently appears to fail, with error 34 "Page not Found" where in fact the request did succeed, was posted as intended and can be seen clear as day in twitter stream.

Now, if I can't trust the error code returned then I can't really go on and keep retrying. How do I know for sure if it succeeds or fails?

RECENT OBSERVATIONS:

Recently, I tried to post a photo from Apple photo app directly and it sent me an alert that read "Tweet may not have been successful". That is funny, because that is basically what I was coming to as my only option in this case. This makes me think that even Apple had to acknowledge that there is not way to tell for sure that post failed when the return does not confirm it.

Dean Davids
  • 4,174
  • 2
  • 30
  • 44
  • Actual log printout is: errors = ( { code = 34; message = "Sorry, that page does not exist"; } – Dean Davids Aug 23 '12 at 23:46
  • You should also share the example URL that you are executing here? – defactodeity Sep 25 '12 at 18:30
  • What about the NSError *error passed to the block? – Moxy Sep 25 '12 at 20:47
  • @defactodeity - build the TWRequest above and don't show as it doesn't seem to be relevant. The request rarely fails, the tweet is successful. My issue is that, some of the time, the response indicates failure even though it did in fact succeed. – Dean Davids Sep 25 '12 at 21:11
  • @Moxy - I have not inspected the NSError, not sure that it returns anything as the post does succeed. I do not read 200 in URLResponse and so test the response data and get the message above. – Dean Davids Sep 25 '12 at 21:15
  • Logically if the NSError is nil then the request succeeded otherwise you'll have to inspect it. – Moxy Sep 25 '12 at 21:23
  • I am not so sure of that. My understanding is that the server is returning the error code, 404 or something like you see when a web page doesn't load. The TWRequest does not consider that an error as it did succeed in its job, sent the post, got a return. I believe the NSError you are talking about would return if the TWRequest was improperly configured and fell flat without ever getting out to be processed. – Dean Davids Sep 25 '12 at 21:33

1 Answers1

2

according to every example found in researching this problem, none of which use any other API than what you are using, and including this example from twitter's own documentation for posting a photo to the API, none of them check the urlResponse code first.

the most that ever seems to be done is this example from twitter's documentation where a GET is performed and then the response is processed. notice that it checks the responseData first, and if it exists, it is simply treated like success. only if there is no responseData is there an attempt to bother looking at the error. the example does not bother with the urlResponse … and neither does any other example i saw in 10 minutes of googling.

(finally, i doubt this matters, or it may be because you cleaned up the example for the display, but you're processing the error on the main-queue when you are not performing any UI. you could do the processing in the handler immediately, and pass along whatever post-processing you do to whatever UI you are trying to display it with. i doubt post-processing the response in the main-queue as opposed to the queue of the handler (as shown in both examples cited here and all other examples i've seen) is really causing a problem, but i wonder if it might cut down on the incidence of false negatives you are seeing. at the very least, it will make your response and any UI display of the response cleaner and more efficient.)

john.k.doe
  • 7,533
  • 2
  • 37
  • 64
  • I see the latter example has no need for the url response as it checks if the array returned is valid. This wouldn't apply in my case, with a POST. So far as I know, the only thing to go on in this case is the URLResponse. You are right about the thread handling, though I don't think that applies in any way to my specific issue. If it hasn't been corrected in my working code, I do intend to allow that to go forward on the calling thread, which is never the main thread. – Dean Davids Sep 30 '12 at 17:03
  • i guess my point was mostly that, in the link in the 1st paragraph, even twitter's own examples don't bother checking the urlResponse for error ... and i just didn't see any other example code that does, either. – john.k.doe Oct 01 '12 at 08:13
  • I appreciate your input and I am not saying you are wrong. Unless I am mistaken, it just doesn't help me much in my situation. With a POST, URLResponse is really all you have to go on. Once it is sent out, how else could I know if it was successful? Most of the time I do get a 200 response and all is well. When it does fail, usually a network error, timeout or something, I get another response. Unfortunately, sometimes I get a 200 response even after a successful tweet which does negate its usefulness. – Dean Davids Oct 01 '12 at 12:22
  • 1
    I've come to the conclusion that, since this is a problem on twitter's part, the best we can do on the client side is to handle it as gracefully as possible (cf. Apple's ambiguous "Tween may not have been successful") – cleverbit Oct 10 '12 at 17:29