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

Question

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, with 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 in between 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 closing 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 behavior 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.

Answer 1

For anyone having the same issue: We were not able to identify why this happens. We "solved" this by not relying on blob/content uris for the mobile version of our application at all. Instead, we use react-native-blob-util to copy the attachment to the applications cache and get a path for it.

At certain points in the life cycle, when we know we don't need the attachment anymore, we delete it again, also using react-native-blob-util.