[0.75.2] Blob not found "sometimes" when accessing a content URI subsequent times

[minikN]

Description

Hello,

we are currently facing an issue when working with blobs in our application. We organize attachments in our application with blob/content uris. The general flow is as follows:

• We use XMLHttpRequest to fetch a binary from our backend
• After having fully received the binary, we use URL.createObjectURL to create a content uri to the attachment (e.g. content://com.gaia.blob/d7809c88-a0e7-4fe6-b049-68d9154d8794?offset=0&size=59301)
• We then feed this URL to a component that is responsible for displaying the binary (Like react-native's Image component)

Due to the architecture of our application, we never use external URLs for attachments (like https://path/to/image.png). Our client accesses a known URL for an attachment (like https://path/to/attachment/<id> (using XMLHttpRequest explained above), which will return the binary directly, we create a content uri for it and manage it using said url. This works very well for the web version of our application (which uses react, not react-native), but in RN, we're facing some issues.

The procedure described above works without a problem on RN, we get a content uri and can feed it to a component to display it, no problem. In some scenarios, we need to access the content uri again after we have already displayed it (meaning fed it to e.g. Image), for example for various actions regarding the attachment (Download, which just copies the attachment to the downloads folder, Open with, Share and so on).
At some point after initially displaying the attachment and trying to access the content uri again, the binary data of the attachment is gone. It reports

[13:22:21.245Z][Console] [java.io.FileNotFoundException: Cannot open content://com.gaia.blob/d7809c88-a0e7-4fe6-b049-68d9154d8794?offset=0&size=59301, blob not found.] 

The difficult part is that we don't know what we do inbetween that breaks things. The user may click on a button, which renders a view, or a bottom sheet or something else, goes to another screen, comes back, tries to open the previously displayed attachment using their default application, and it's broken.

To add to this, it doesn't happen every time. We have been unable to set up a scenario that reproduces this bug consistently. Sometimes accessing the attachment after the user opened a bottom sheet (note: This bug isn't related to us opening a bottom sheet, we have the same problem everywhere we interact with attachments, this is just an example) and closed it again will work for 2, 3 times, and then it breaks, sometimes it breaks right away.

I'm sorry I'm being vague here and can't describe the issue any further, but we simply don't know what we're doing between invoking createObjectURL and the error mentioned above. Unfortunately the project is closed source so I can not provide a working example to test this.

In the web version of our application, we use revokeObjectURL (at a point when we are sure we don't need the binary anymore). However, due to revokeObjectURL not being implemented in RN, we obviously don't do this here.

My gut tells me, that the binary is getting garbage collected. After looking through the RN's code base, I noticed that the close function in react-native/Libraries/Blob/Blob.js:135 does exactly that. However I added a log entry to it and verified that it's never getting called throughout this process.

What we sometimes see in log cat are warnings like

2024-11-19 13:58:32.739 12664-12672 System                  com.gaia                             W  A resource failed to call close. 

Although we're not sure whether or not they are related.

Again, I'm sorry to not be able to provide further information. I'd be happy to give additional feedback if needed. If individual pieces of code are needed, I may be able to provide them, unfortunately, due to the project not being public, I can't provide a reproducible example. I guess to have some foundation for a discussion:

• Is there any way to check if the binary is being garbage collected by hermes?
• Can one tweak the GC behaviour in any way (when to gc what)?

Again, we're not even sure GC is the problem here, but it's the only thing we can think of as of now.

We are currently running 0.75.2, due to some dependencies, we're currently unable to update to a later version. It's also unknown for how long this problem has existed, we first noticed it two weeks ago.

Steps to reproduce

See above

React Native Version

0.75.2

Affected Platforms

Runtime - Android, Runtime - iOS

Output of npx react-native info

System:
  OS: Linux 6.10 Arch Linux
  CPU: (16) x64 AMD Ryzen 7 5700U with Radeon Graphics
  Memory: 7.96 GB / 30.74 GB
  Shell:
    version: "5.9"
    path: /usr/bin/zsh
Binaries:
  Node:
    version: 20.17.0
    path: /usr/bin/node
  Yarn: Not Found
  npm:
    version: 10.8.3
    path: /usr/bin/npm
  Watchman: Not Found
SDKs:
  Android SDK: Not Found
IDEs:
  Android Studio: AI-241.18034.62.2412.12266719
Languages:
  Java: Not Found
  Ruby: Not Found
npmPackages:
  "@react-native-community/cli":
    installed: 14.0.1
    wanted: ~14.0.1
  react:
    installed: 18.3.1
    wanted: ~18.3.1
  react-native:
    installed: 0.75.2
    wanted: 0.75.2
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false
-----------------------------------
System:
  OS: macOS 15.1
  CPU: (12) arm64 Apple M2 Pro
  Memory: 104.42 MB / 32.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.9.0
    path: /usr/local/bin/node
  Yarn:
    version: 4.3.1
    path: /usr/local/bin/yarn
  npm:
    version: 8.19.4
    path: /usr/local/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.15.2
    path: /Users/bob/.gem/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.0
      - iOS 18.0
      - macOS 15.0
      - tvOS 18.0
      - visionOS 2.0
      - watchOS 11.0
  Android SDK: Not Found
IDEs:
  Android Studio: Not Found
  Xcode:
    version: 16.0/16A242d
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 20.0.2
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 14.0.1
    wanted: ~14.0.1
  react:
    installed: 18.3.1
    wanted: ~18.3.1
  react-native:
    installed: 0.75.2
    wanted: 0.75.2
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false

Stacktrace or Logs

[13:22:21.245Z][Console] [java.io.FileNotFoundException: Cannot open content://com.gaia.blob/d7809c88-a0e7-4fe6-b049-68d9154d8794?offset=0&size=59301, blob not found.]

Reproducer

https://github.com/react-native-community/reproducer-react-native

Screenshots and Videos

No response

[react-native-bot]

Tip

Newer version available: You are on a supported minor version, but it looks like there's a newer patch available - 0.75.4. Please upgrade to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases.

[react-native-bot]

Tip

Newer version available: You are on a supported minor version, but it looks like there's a newer patch available - undefined. Please upgrade to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases.

[react-native-bot]

Warning

Missing reproducer: We could not detect a reproducible example in your issue report. Please provide either:

• If your bug is UI related: a Snack
• If your bug is build/upgrade related: a project using our Reproducer Template
• Otherwise send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.