Retrofit: Retrofit unexpected value of 'canceled' flag in 'onFailure()' after cancelling all Requests

[hkuadithya]

What kind of issue is this?

• [ ] Question. This issue tracker is not the place for questions. If you want to ask how to do
  something, or to understand why something isn't working the way you expect it to, use Stack
  Overflow. https://stackoverflow.com/questions/tagged/retrofit

• [x] Bug report. If you’ve found a bug, spend the time to write a failing test. Bugs with tests
  get fixed. Here’s an example: https://gist.github.com/swankjesse/6608b4713ad80988cdc9

• [ ] Feature Request. Start by telling us what problem you’re trying to solve. Often a solution
  already exists! Don’t send pull requests to implement new features without first getting our
  support. Sometimes we leave features out on purpose to keep the project small.

[hkuadithya]

I am using the latest version of Retrofit. I am performing multiple requests in an activity and in onDestroy method, i.e. when the activity ends, I wish to terminate all the pending requests and hence I am calling okHttpClient.dispatcher().cancelAll().

The onFailure method of the request is handled in this manner :-

        @Override
        public void onFailure(Call<APIResponseClass> call, Throwable t) {

            if (call != null && !call.isCanceled()) {
                // Call is not cancelled, Handle network failure

                onNetworkFailure(call, t);

            } else if (call != null && call.isCanceled()){

                // Call is CANCELLED. IGNORE THIS SINCE IT WAS CANCELLED.

            }
        }

Problem is, I'm receiving an unexpected behavior in onFailure method. Despite the call being cancelled through okHttpClient.dispatcher().cancelAll() , the canceled flag is received as false, which should have been true, i.e. call.isCancelled() should have been true.

However, the variable Throwable t surprisingly is sending the cause as java.io.IOException: Canceled and the detailMessage as Canceled . I have added the Screenshot of my debugger...

My question is, if the cause of the exception is determined as the cancellation of the request, why isn't the canceled flag displaying proper result??

I have been referring to this link for cancelling ongoing retrofit requests...

[JakeWharton]

The flag is false because as far as Retrofit is concerned you never called cancel(). I suppose we could delegate cancelation status to the underlying Call or at the very least combine the two statuses together.

[hkuadithya]

@JakeWharton Are you trying to say that okHttpClient.dispatcher().cancelAll() is not a reliable method to handle cancellation of requests?

Thing is, when the request get cancelled, I need to handle it in a specific way but due to this discrepancy, this piece of code gets executed...

           if (call != null && !call.isCanceled()) {
                // This method is called. ACTUALLY THIS SHOULDN'T BE SINCE REQUEST IS CANCELLED....

                onNetworkFailure(call, t);

            } 

Jake, Is there a workaround for this? Can I modify the method this way (something like this)?

           if (call != null && !call.isCanceled()  &&  !t.getCause().getMessage().equals("Canceled")) {

                // IF THE EXCEPTION MESSAGE IS "Canceled", this code will not be executed !!!
                onNetworkFailure(call, t);

            } 

What do you recommend? In your opinion, what is the best and reliable way to check if a request has been cancelled or not?

[JakeWharton]

No, I just said that from Retrofit's perspective you didn't cancel the
request. You canceled the underlying request from beneath it which it just
sees as a normal failure currently.

On Fri, Nov 11, 2016 at 12:49 AM Adithya H K Upadhya <
[email protected]> wrote:

@JakeWharton https://github.com/JakeWharton Are you trying to say that
okHttpClient.dispatcher().cancelAll() is not a reliable method to handle
cancellation of requests?

Thing is, when the request get cancelled, I need to handle it in a
specific way but due to this discrepancy, this piece of code gets
executed...

       if (call != null && !call.isCanceled()) {
            // This method is called. ACTUALLY THIS SHOULDN'T BE SINCE REQUEST IS CANCELLED....

            onNetworkFailure(call, t);

        }

Jake, Is there a workaround for this? Can I modify the method this way
(something like this)?

       if (call != null && !call.isCanceled()  &&  !t.getMessage().equals("Canceled")) {

            // IF THE EXCEPTION MESSAGE IS "Canceled", this code will not be executed !!!
            onNetworkFailure(call, t);

        }

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/square/retrofit/issues/2076#issuecomment-259886383,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEERbwMQUEJ0ma5Wq7eiL4_kyjR9HHks5q9AH4gaJpZM4KvcXW
.

[hkuadithya]

@JakeWharton Sorry for misunderstanding. Could you recommend a temporary workaround for this to check RELIABLY if the request has been cancelled or not when we cancel requests through client.dispatcher().cancelAll() ?

May be something like this

if(t.getCause().getMessage().equalsIgnoreCase("Canceled") {
        // REQUEST IS CANCELED NOW. HURRAY !
}

[JakeWharton]

You can try checking the message like that but it's not guaranteed to
always be "Canceled". It's probably good enough for now though.

On Fri, Nov 11, 2016 at 12:57 AM Adithya H K Upadhya <
[email protected]> wrote:

@JakeWharton https://github.com/JakeWharton Sorry for misunderstanding. _Could
you recommend a temporary workaround for this to check RELIABLY if the
request has been cancelled or not? When we cancel requests through
client.dispatcher().cancelAll()_

May be something like this

if(t.getMessage().equalsIgnoreCase("Canceled") {
// REQUEST IS CANCELED NOW. HURRAY !
}

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/square/retrofit/issues/2076#issuecomment-259887276,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEfrE_z02glzIlDYP32OO0CpC-FiQks5q9APZgaJpZM4KvcXW
.