Inconsistent behavior when cancelling request with range header (ios vs. android)

[schumannd]

react-native-cli: 2.0.1
react-native: 0.51.0
RNFetchBlob: 0.10.8

So when downloading something like so:

task = RNFetchBlob.config({
      path: dest,
      overwrite: false,
      IOSBackgroundTask: true,
      indicator: true,
    }).fetch('GET', url, {
      Range: `bytes=${size}-`,
    });
task.then(handleSuccess)
  .catch(handleError)

and then calling task.cancel(), I observe different behavior on iOS vs android.

iOS:
handleError(err) gets called where err.message === 'cancelled'. So this is nicely catcheable.

android:
handleSuccess(success) is called, where success has a HTTP code 206, which suggests that the range request was satisfied? It looks exactly like the response I get when the request finished successfully. Here is the content of respInfo, and it is the same whether I cancel the task or not:

headers: [
Accept-Ranges: "bytes"
Content-Length: "20177379"
Content-Range: "bytes 0-20177378/20177379"
Content-Type: "audio/mp3"
Date: "Fri, 04 May 2018 08:39:03 GMT"
ETag: ""...""
Last-Modified: "Tue, 12 Dec 2017 13:36:08 GMT"
Server: "AmazonS3"
x-amz-id-2: "..."
x-amz-request-id: "..."
]
redirects: ["https://s3-eu-west-1.amazonaws.com/.../efaaa2177b5f494390896e70d5444837.mp3"]
respType:  ""
rnfbEncode: "path"
state: "2"
status: 206
taskId: "jwy3rlqv5rkr1deb205f4p"
timeout: false

Any takes on why this happens?

[gigby]

Ha-ha, funny situation:

(IS_ANDROID ? 'Canceled' : 'cancelled')

[schumannd]

Can you elaborate?

[gigby]

Yes. I just showed some funny aspect of the issue created by you. In Android returned error.msg === 'Canceled' but in iOS error.msg === 'cancelled'

[schumannd]

If that is the case, I believe it should be fixed

[CapitanRedBeard]

Not really sure what @gigby is saying but the issue is on iOS task.cancel() throws a catchable error while Android it doesn't throw an error and succeeds normally. There is PR up here => #363