React-native-fs: RNFS.downloadFile resolves without bytesWritten very often (RNFS v1.5.1)

[tomprogers]

react-native v0.33.0
react-native-fs v1.5.1

I make a habit of checking the size-on-disk of each file I download, because I've noticed that sometimes a download operation will produce a truncated file (less than 200 bytes, for a file in Amazon S3 that's 90k).

Lately, I've started relying on the resolution value of RNFS.downloadFile, which is documented as containing jobId, bytesWritten, and statusCode. Today I've discovered that bytesWritten is often undefined, even though the file downloaded correctly and the statusCode is 200.

I used RNFS.stat to verify the result of RNFS.downloadFile. Even though bytesWritten is undefined, stat reports a size of 70k on disk (the correct size).

By "very often," I mean that bytesWritten is incorrect 74 times out of 75. I've been building a caching module, and while putting it through its paces I've done nearly 1000 downloads of files around 90k.

Apologies if this is fixed in the newest version of RNFS.

[johanneslumpe]

@tomprogers were yo able to look into this issue further and come to a conclusion where we might have a bug?

[tomprogers]

@johanneslumpe Sorry, but no. I'm not an Obj-C dev. I can't trace or debug execution once it leaves the JS world. I see some code in Downloader.m that appears relevant, but I'm not equipped to figure out why it's not working.

[br4nnigan]

i'm experiencing this too, byteswritten is undefined like 1 in 5

[dojiboy9]

For what it's worth, I am getting this issue as well. But I seem to be getting it 100% for specific files.

I have been testing with some mp4 files and one jpeg file, and it consistently returns undefined for bytesWritten for the jpeg file, but returns correct information for the mp4 files.

Maybe it has something to do with small files? E.g. there is some kind of race that causes bytesWritten to appear undefined if the file is really small and the download completes too quickly? (random thoughts)

[a-koka]

I get this about once in 20 times. It is definitely happening for small files under 100KB in my case.

[aschenkel]

Also getting this error.

Is it okey to assume that if the DownloadResult promise resolves then the file has been correctly downloaded? So instead of checking if bytesWritten is equal to downloaded file size I do something like:

    const downloadInfo = await fileManager.downloadFile({
      fromUrl: asset.url,
      toFile: `${AssetsManager.ASSETS_BASE_PATH}${asset.version}/${asset.name}`,
      headers: getOpts.headers,
    })

    if (await downloadInfo.promise) {
      // ASSET HAS BEEN DOWNLOADED!
    }

I have tested this by removing internet connection and it worked (promise didn't resolve successfully). Am I missing a case where this may fail?

[a-koka]

I have not tested this with the recent updates but I have had the promise resolve incorrectly. Below is a snippet of what works for me. I wrap the entire download call into a promise and resolve it only if the checks below pass.

// bytesWritten comes back undefined at times
// https://github.com/johanneslumpe/react-native-fs/issues/181
if (statusCode === 200 && (!bytesWritten || bytesWritten === contentLength)) {
  // Success
}

[tomprogers]

It's still a fact that bad bytesWritten is a bug that ought to be fixed.

Yes, the promise resolves IFF the download completes, but without bytesWritten, it's impossible to know whether the data you saved to disk is the data you expected. Common example: make an incorrect "download" request to a URL that responds with an error page. Naive download code will unwittingly save the error HTML as a file on the device. The workaround is to make a second FS call to get the size of the new file from disk, but that's additional complexity that this module is supposed to eliminate.

Fix this bug.

[a-koka]

I'm now seeing some very strange behavior with bytesWritten all over the place ie. sometimes larger than contentLength, sometimes smaller and obviously undefined at times.