🔥 Error Using loadBundle() in Firestore: Unknown error or an error from a different error domain.

[TheRealMikeD]

Issue

When calling firestore().loadBundle(bundle) in a React Native project, some bundles cause the following error to be thrown on iOS:
[firestore/unknown] Unknown error or an error from a different error domain.

On Android, the same line of code throws a different error:
[firestore/invalid-argument] Client specified an invalid argument. Note that this differs from failed-precondition. invalid-argument indicates arguments that are problematic regardless of the state of the system (e.g., an invalid field name).

Other bundles work as expected.
When the error occurs, I have confirmed that the bundle text has been downloaded correctly from the endpoint. The call to loadBundle() fails with the error.

Sample code:

const response = await fetch(apiUrl);
const bundle = await response.text();
await firestore().loadBundle(bundle); // <- Error occurs here.

I'm not sure why some bundles work as expected, and others don't. They are all created using the same code (NodeJS/Firebase Cloud Funtions):

query = db.collection('exampleCol');
const snap = await query.get();
const bundleBuffer = db.bundle('exampleBundleID').add('exampleNamedQuery', snap).build();
return bundleBuffer;

I am just speculating here, but perhaps it is some sort of parsing error, maybe related to unexpected characters in the data?

I know there have been issues filed around this problem in the past (6224, for example), but those issues did not indicate any fixes or workarounds, and the problem remains.

---

Project Files

This is an Expo managed workflow project, with a custom Expo dev client, which uses plugins.
The project is built using the EAS build service, not on the local machine. So I don't have any Podfile or gradle files.

Javascript

Click To Expand

package.json:

{
  "name": "XXXXX",
  "version": "1.0.0",
  "scripts": {
    "start": "expo start --dev-client",
    "android": "expo run:android",
    "ios": "expo run:ios",
    "web": "expo start --web",
    "eject": "expo eject",
    "postinstall": "patch-package"
  },
  "dependencies": {
    "@babel/plugin-transform-logical-assignment-operators": "^7.24.1",
    "@expo/config-plugins": "~7.8.0",
    "@expo/vector-icons": "^14.0.0",
    "@miblanchard/react-native-slider": "^2.1.0",
    "@react-native-async-storage/async-storage": "1.21.0",
    "@react-native-community/datetimepicker": "^8.0.0",
    "@react-native-firebase/analytics": "^18.7.3",
    "@react-native-firebase/app": "^18.7.3",
    "@react-native-firebase/auth": "^18.7.3",
    "@react-native-firebase/firestore": "^18.7.3",
    "@react-navigation/bottom-tabs": "^6.5.11",
    "@react-navigation/drawer": "^6.4.3",
    "@react-navigation/material-top-tabs": "^6.6.5",
    "@react-navigation/native": "^6.0.11",
    "@react-navigation/native-stack": "^6.7.0",
    "@react-navigation/stack": "^6.3.29",
    "@sentry/react-native": "5.19.1",
    "@types/react": "~18.2.45",
    "deprecated-react-native-prop-types": "^2.3.0",
    "expo": "^50.0.15",
    "expo-application": "~5.8.3",
    "expo-av": "~13.10.5",
    "expo-blur": "~12.9.2",
    "expo-build-properties": "~0.11.1",
    "expo-constants": "~15.4.5",
    "expo-dev-client": "~3.3.11",
    "expo-device": "~5.9.3",
    "expo-file-system": "~16.0.8",
    "expo-font": "~11.10.3",
    "expo-linking": "~6.2.2",
    "expo-notifications": "~0.27.6",
    "expo-splash-screen": "~0.26.4",
    "expo-sqlite": "~13.4.0",
    "expo-status-bar": "~1.11.1",
    "expo-updates": "~0.24.12",
    "html-entities": "^2.4.0",
    "intl": "^1.2.5",
    "jsdom-jscore-rn": "^0.1.8",
    "lodash": "^4.17.21",
    "lottie-react-native": "6.5.1",
    "luxon": "^3.3.0",
    "patch-package": "^6.4.7",
    "promise": "^8.3.0",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "react-native": "^0.73.6",
    "react-native-collapsible": "^1.6.0",
    "react-native-fast-image": "^8.6.3",
    "react-native-gesture-handler": "~2.14.0",
    "react-native-keyboard-aware-scroll-view": "^0.9.5",
    "react-native-linear-gradient": "^2.8.3",
    "react-native-pager-view": "6.2.3",
    "react-native-purchases": "^7.6.0",
    "react-native-reanimated": "~3.6.2",
    "react-native-render-html": "^6.3.4",
    "react-native-safe-area-context": "4.8.2",
    "react-native-screens": "^3.31.1",
    "react-native-settings-components": "^0.0.2",
    "react-native-snap-carousel": "^3.9.1",
    "react-native-svg": "14.1.0",
    "react-native-swiper": "^1.6.0",
    "react-native-tab-view": "^3.5.2",
    "react-native-web": "~0.19.6",
    "react-native-webview": "13.6.4"
  },
  "devDependencies": {
    "@babel/core": "^7.20.0",
    "@types/lodash": "^4.14.202",
    "@types/luxon": "^3.4.2",
    "typescript": "^5.4.5"
  },
  "resolutions": {
    "promise": "^8.0.3"
  },
  "private": true
}

firebase.json for react-native-firebase v6:

# N/A

iOS

Click To Expand

ios/Podfile:

• I'm not using Pods
• [] I'm using Pods and my Podfile looks like:

# N/A

AppDelegate.m:

// N/A

---

Android

Click To Expand

Have you converted to AndroidX?

• my application is an AndroidX application?
• I am using android/gradle.settings jetifier=true for Android compatibility?
• I am using the NPM package jetifier for react-native compatibility?

android/build.gradle:

// N/A

android/app/build.gradle:

// N/A

android/settings.gradle:

// N/A

MainApplication.java:

// N/A

AndroidManifest.xml:

<!-- N/A -->

---

Environment

Click To Expand

react-native info output:

System:
  OS: macOS 12.7.4
  CPU: (8) x64 Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
  Memory: 74.09 MB / 32.00 GB
  Shell:
    version: 3.2.57
    path: /bin/bash
Binaries:
  Node:
    version: 20.12.2
    path: ~/.nvm/versions/node/v20.12.2/bin/node
  Yarn:
    version: 1.22.18
    path: /usr/local/bin/yarn
  npm:
    version: 10.5.0
    path: ~/.nvm/versions/node/v20.12.2/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.15.2
    path: /usr/local/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 22.2
      - iOS 16.2
      - macOS 13.1
      - tvOS 16.1
      - watchOS 9.1
  Android SDK: Not Found
IDEs:
  Android Studio: 2022.3 AI-223.8836.35.2231.10811636
  Xcode:
    version: 14.2/14C18
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 11.0.15.1
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.73.6
    wanted: ^0.73.6
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: Not found
  newArchEnabled: Not found
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

• Platform that you're experiencing the issue on:
  • iOS
  • Android
  • iOS but have not tested behavior on Android
  • Android but have not tested behavior on iOS
  • Both
• react-native-firebase version you're using that has this issue:
  • 18.7.3
• Firebase module(s) you're using that has the issue:
  • firestore
• Are you using TypeScript?
  • N

---

• 👉 Check out React Native Firebase and Invertase on Twitter for updates on the library.

[TheRealMikeD]

I found a clue. I scrubbed through all the data in the source collection of one of the bundles that was causing the error, and found a bullet point character inside a text (String) field:
• (Option+8 on a Mac keyboard)

I removed that character from the database, regenerated the bundle, and now that one works as expected.
There is still another bundle which is causing the error, so I'm going to see if I can find an offending character in that collection.
But for the moment at least, we know that loadBundle() is choking on that bullet point character.

[mikehardy]

That's very strange - I don't believe we're doing anything special in particular at this layer, you might see if you can reproduce this using one of the firestore quickstarts for firebase-android-sdk or firebase-ios-sdk (if you can, then filing an issue in the respective repository/repositories and linking it back here would be awesome)

[TheRealMikeD]

@mikehardy, thanks for the response. I'm afraid those quickstarts are way outside my comfort zone. I'm a JavaScript coder, not Swift or Java, and I don't know my way around XCode or Android Studio at all. I let Expo/EAS do that nitty-gritty heavy lifting for me.

If it's helpful for you, I can share the API endpoint of a bundle that is failing to load:
(REDACTED)
I scoured through the output a few days ago, but nothing jumped out at me as something that would obviously cause a parse error. Maybe you will find something that I couldn't.

[mikehardy]

The beauty of the quickstarts is that they are made for people who have zero comfort in the area - I'd strongly recommend giving them a try

I won't have time to investigate specific bundles unfortunately - I think this really will be an underlying problem with the native SDKs or cloud firestore behind it's APIs, thus the guidance for a minimal reproduction based on the quickstart.

It is also possible if you asked on stackoverflow with the correct sort of firebase / firestore tags and described the problem really well that someone from the firebase team upstream / related to the native SDKs we wrap here may be able to help

[TheRealMikeD]

OK, I cloned the quickstart for ios and (eventually) got it to run in a simulator. Can you please explain what it is that you want me to do with the quickstart that will help with finding the underlying problem in this issue?

[mikehardy]

Check the reference docs for load bundle and basically copy paste their code but with your bundle name (can also use the react-native-firebase iOS code as an example). Whatever quick and dirty thing works to get your problematic bundle loaded using the native apis

The only goal is to demonstrate the failure without react-native-firebase as an intermediate layer, that way the upstream team will accept it as an issue and fix underlying problem if it reproduces

[TheRealMikeD]

@mikehardy, that sounds like a decent plan. Unfortunately, I seem to have accidentally fixed the bundle. How did I do that? Well...

The query that the bundle was based on includes/excludes documents based on a boolean field. In an attempt to figure out which document was causing the error in the client, I went through the documents in the collection one-by-one and flipped that boolean field so that they would be excluded from the query. My idea was that, once the bundle no longer threw an error when loading, I would have found the offending document, and then I could scrutinize that document to try to figure out what exactly about it was causing the issue.

What happened was that I did indeed get to a point where the bundle no longer threw an error. When I found what seemed to be the offending document, I flipped the boolean field back again so that it would once again be included in the query. And the bundle still loaded without error, whether that document was included or not. Then, I flipped the field back on all the documents that I had changed, so that the set of documents was the same as when the error was first encountered. And the bundle loaded as expected, and I could no longer reproduce the error. I have no idea what changed in the bundle that allow it to load correctly now, even though the data contents are identical to when the error was occurring.

Needless to say, this is confusing at best. But it unfortunately leaves me in a state in which I can no longer test this bug. It also leaves me in a state in which I don't feel confident that the bug won't reappear at some random point in the future. So my solution for the app that I am working on is to discontinue the use of bundles, and instead just provide JSON data via my REST API (which uses the same Cloud Functions/Cloud Hosting/CDN infrastructure, and the same caching advantages).

So, I suppose that leaves this issue as not reproducible for the time being. I'm sorry about that. I suspect the problem will rear its head again for someone at some point. And perhaps that person will come across this issue and be able to add some helpful info from their own case. Meanwhile, thank you for your help.

[mikehardy]

reluctantly closing since it seems there is something going on, but not actionable at the moment