Fix premature blob deallocation during FileReader reads

[heecheolman]

Summary:

FileReader.readAsText / readAsDataURL / readAsArrayBuffer pass only the plain blob.data descriptor to the native module and retain no reference to the Blob instance itself. If the caller also drops its reference, the Blob — and the BlobCollector attached to blob.data.__collector — becomes unreachable while the native read is still in flight. When GC runs in that window, the collector's finalizer unconditionally removes the bytes from the native blob store (BlobCollector.cpp calls BlobModule.remove() on Android; RCTBlobCollector.mm calls [RCTBlobManager remove:] on iOS), and the pending read rejects with "The specified blob is invalid" (Android) / "Unable to resolve data for blob" (iOS).

This is not an exotic case: React Native's fetch polyfill (whatwg-fetch) reads blob bodies exactly this way — readBlobAsText creates a FileReader, calls reader.readAsText(blob), and keeps a reference only to the reader. So a plain fetch(url).then(r => r.json()), where the Response is not otherwise retained, is subject to this race. This matches the symptom profile of #56884: intermittent failures under many concurrent fetches (GC pressure plus native-module thread-hop latency), affecting both platforms, and disappearing when the same flow is rewritten with async/await — the suspended frame keeps the Response (and therefore the Blob and its collector) reachable, which is exactly the reference this fix restores.

The fix retains the Blob on the FileReader instance until the native read settles, completing the reference chain: pending native promise → callbacks → reader → _blob → Blob → collector. The reference is cleared when the current read settles (after the existing read-id staleness check, so a read abandoned by abort() cannot drop a newer read's reference) and in abort() itself, before the abort event is dispatched, so a read started from an abort handler is retained correctly. Memory impact is negligible: the native bytes must live until the read completes anyway — this change only guarantees they do.

The root cause is in the shared JS layer, so both Android and iOS are fixed.

Fixes #56884

Related prior art: #31392 fixed a different premature-deallocation path in the same subsystem (blob.slice() creating a second collector for the same blobId).

Changelog:

[GENERAL] [FIXED] - Retain Blob reference in FileReader during pending native reads to prevent premature deallocation by BlobCollector

Test Plan:

• yarn jest packages/react-native/Libraries/Blob/__tests__/FileReader-test.js — 19 passed, including 4 new tests: the blob is retained while a read is pending, released on resolve / reject / abort(), and a stale read settling after abort does not drop a newer read's blob.
• yarn flow check — no errors. eslint on both changed files — clean.
• The GC race itself cannot be reproduced deterministically under Jest (it requires a real engine GC collecting the Blob between dispatch and native execution), so the unit tests assert the reference-retention behavior instead. A deterministic on-device repro is in the issue comment below / response.text() fails with "Unable to resolve data for blob" under concurrent fetch (Hermes, iOS device) #56884.

[meta-cla]

Hi @heecheolman!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[meta-codesync]

@fabriziocucci has imported this pull request. If you are a Meta employee, you can view this in D114576384.