Regression in 0.24.10: streaming a response with no Content-Length to a file path truncates it at 8 KB

[AjayFrancisTechversant]

Summary

Since 0.24.10, .config({ path }).fetch(...) (stream-to-file mode) writes only the first 8 KB (8192 bytes) of a response when the server does not send a Content-Length header. The rest of the body is silently dropped, producing a truncated/corrupt file. 0.24.9 writes the full file correctly — this is a regression introduced between 0.24.9 and 0.24.10.

Environment

react-native-blob-util	0.24.10 (broken) — 0.24.9 works
react-native	0.85.3
Platform	Android (confirmed on emulator + physical device, Hermes). iOS not yet verified.
Server	Responds over HTTP/2 with the file bytes but no Content-Length header (chunked/streamed).

Steps to reproduce

1. Have a server endpoint that returns a binary file (e.g. a ~13 KB PDF) without a Content-Length response header.
2. Download it to a file using stream-to-path mode:

const res = await ReactNativeBlobUtil
  .config({ path: localFilePath, timeout: 20000 })
  .fetch('POST', url, headers, body);

// res.info().status === 200

3. Inspect the file on disk.

Expected

The file on disk is the full response body (e.g. 13264 bytes).

Actual

The file on disk is exactly 8192 bytes (the first 8 KB), regardless of the true size. The download reports success (status === 200), so there's no error surfaced — the file is just silently truncated and therefore corrupt. (In our case react-native-pdf then rejects it as "Unsupported URL".)

Key observation — the network read is fine; the file writer is the problem

On the same 0.24.10 build and the same endpoint:

• Reading the response into memory returns the complete body:

  const full = res.base64();          // full 13264 bytes ✅
  await ReactNativeBlobUtil.fs.writeFile(path, full, 'base64');  // full file ✅

• Streaming the response directly to a file path truncates it:

  .config({ path }).fetch(...)        // only 8192 bytes on disk ❌

So the bytes are received correctly off the wire — the truncation is in the stream-to-file write path when Content-Length is absent (it appears to stop after the first read buffer / 8 KB chunk
rather than draining the stream to EOF).

Regression range

• 0.24.9 (published 2026-05-19) — writes the full file ✅
• 0.24.10 (published 2026-06-19) — truncates at 8 KB ❌

Downgrading to 0.24.9 fully resolves it. It looks like a change in the native download/stream-write logic (Android) between these two patch releases.

Workaround

Either pin to 0.24.9, or avoid stream-to-path and buffer in memory (res.base64() + is undesirable for large files

[Prajwaltechversant]

+1

[maneesh-techversant]

Root cause: the stream-to-file drain switched from bytes() to byteStream() in 0.24.10

I bisected the two published tarballs (0.24.9 vs 0.24.10). The regression is one change in android/src/main/java/com/ReactNativeBlobUtil/ReactNativeBlobUtilReq.java, in case FileStorage:.

0.24.9 (works):

ResponseBody responseBody = resp.body();
responseBody.bytes();            // drains the whole body to EOF

0.24.10 (truncates):

java.io.InputStream drainStream = responseBody.byteStream();
byte[] drainBuf = new byte[65536];
while (drainStream.read(drainBuf) != -1) { }   // exits after the first 8192-byte segment

Why it stops at exactly 8192 bytes

The file is written by ReactNativeBlobUtilFileResp.source() → ProgressReportingSource, which on each read(sink, byteCount) reads a network chunk and writes it to the destination file (ofStream.write(...)) but never writes those bytes into the Okio sink buffer — it returns the count and leaves the sink empty. (This class is unchanged between the two versions.)

• responseBody.bytes() drains via Okio's Buffer.writeAll(source), which loops while (source.read(buf, Segment.SIZE) != -1) and inspects only the return value, so it keeps pulling until true network EOF → the whole file is written.
• responseBody.byteStream() returns Okio.buffer(source).inputStream(). Its InputStream.read() calls source.read(buffer, 8192) (one Okio segment), then reads out of the sink buffer — which ProgressReportingSource left empty — so it returns -1 after the first segment. The drain loop exits with 8192 bytes on disk.

The cutoff being exactly 8192 (Okio's Segment.SIZE) rather than the 65536-byte drainBuf confirms the stop happens inside Okio's buffering layer after a single segment. In short: ProgressReportingSource doesn't fill the sink (it side-effects to the file instead); bytes()/writeAll tolerated that, but byteStream() + InputStream.read() does not.

Note that by this reading the truncation is inherent to any stream-to-file download that goes through this new drain path, so it's worth checking whether Content-Length-present downloads are affected too.

Suggested fix — either revert to responseBody.bytes(), or, to keep the intended >2 GB support, drain the Okio Source directly (loop source.read(buffer, Segment.SIZE) and clear the buffer each iteration) instead of going through byteStream()/InputStream. Alternatively, make ProgressReportingSource.read() honor the Okio Source contract by writing the chunk into the sink buffer as well as the file.

[kenyipp]

Independently confirmed the same root cause and fix while debugging this in production (0.24.10) for our React Native / Expo app on Android.

Reproduced with a legal-agreement PDF served from S3 via react-native-pdf's FileStorage download path — every attempt truncated at exactly 8192 bytes (confirmed both on-device and by pulling the cached file and checking for the missing %%EOF trailer), matching the Segment.SIZE explanation above exactly. A direct curl of the same URL confirmed the source file was intact (801,025 bytes), ruling out any server/network cause.

The fix in PR #474 (sink.write(bytes, 0, (int) read) alongside the existing ofStream.write(...) in ProgressReportingSource.read()) resolved it for us — rebuilt the native APK with the patch applied and confirmed the same document now downloads and renders the full file.

Worth noting for anyone hitting this via react-native-pdf: this truncation also gets masked by a separate bug in that library (a .then() chained after .catch() on the same promise in _downloadFile()), which causes the truncated file to be silently copied into the final cache path and reported as a generic "corrupted PDF" error instead of the real "Download interrupted." — opening a companion issue/PR there.

+1 for merging #474 — this is a real regression affecting any file >8KB downloaded via FileStorage, not just PDFs.