firebase-ios-sdk: FIRESTORE INTERNAL ASSERTION FAILED: Failed to open DB

This issue happens for me when I run the app in SwiftUI Preview, and then try to launch it. Xcode keeps the app’s process alive - even after the Preview is no longer visible in Xcode. Having those two processes open at the same time leads to this error.

How to fix:

1. Open Activity Monitor app
2. Find process of your app
3. Kill it

It’s annoying to deal with so if anyone from Firebase team can fix it, that’d be great 😃

Receiving this error too:

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'FIRESTORE INTERNAL ASSERTION FAILED: Failed to open DB: Internal: Failed to open LevelDB database at /Users/user/Library/Developer/CoreSimulator/Devices/75E41D4A-1A35-4B35-A073-9591F9932BDF/data/Containers/Data/Application/F9074D72-BDD3-4A9F-8AB6-6E77DA2571C3/Library/Application Support/firestore/__FIRAPP_DEFAULT/project-25f32/main: LevelDB error: IO error: lock /Users/user/Library/Developer/CoreSimulator/Devices/75E41D4A-1A35-4B35-A073-9591F9932BDF/data/Containers/Data/Application/F9074D72-BDD3-4A9F-8AB6-6E77DA2571C3/Library/Application Support/firestore/__FIRAPP_DEFAULT/project-25f32/main/LOCK: Resource temporarily unavailable (expected created.ok())'
terminating with uncaught exception of type NSException
CoreSimulator 757.3 - Device: iPhone 12 (75E41D4A-1A35-4B35-A073-9591F9932BDF) - Runtime: iOS 14.4 (18D46) - DeviceType: iPhone 12

It crash on the very beginning, right after the launch screen disappears. Running on the new M1 MacBook Pro, this wasn’t shown on my previous MacBook Pro using the Intel chip. I need to clean the build folder, restart the simulator, sometimes even the system needs to reboot, to run the app on the simulator.

Having the same issue randomly on my M1 macOS project. Using Swift Package manager. Latest versions. Cleared derived data and reset the cache of the package manager. Still not working.

FIRESTORE INTERNAL ASSERTION FAILED: Failed to open DB: Internal: Failed to open LevelDB
database at /Users/<ME>/Library/Application Support/firestore/__FIRAPP_DEFAULT/<APP_ID>/main: LevelDB error: 
IO error: lock /Users/<ME>/Library/Application Support/firestore/__FIRAPP_DEFAULT/<APP_ID>/main/LOCK: 
Resource temporarily unavailable (expected created.ok())

What helped me was to disable persistence. I started having the issue, when I started implementing Unit Tests. I assume, that the Tests created some kind of 2nd instance. Running for now without persistence, and will then figure out how to add it for production, but disable it for Unit Tests.

let settings = FirestoreSettings()
settings.isPersistenceEnabled = false
        
let firestore = Firestore.firestore()
firestore.settings = settings

@ilnur-nazmutdinov-spark As mentioned in previous comments https://github.com/firebase/firebase-ios-sdk/issues/5423#issuecomment-617309806 and https://github.com/firebase/firebase-ios-sdk/issues/5423#issuecomment-617376885, Firestore will crash if persistence is enabled and the file system is locked. The reproduction steps you listed definitely result in Firestore attempting to open its database which the file system is locked. Unfortunately, we don’t have a fix for this, and don’t have any immediate plans to fix it (it’s a complicated issue). Please check the workarounds outlined in those previous comments, or disable persistence if your app doesn’t need it.

@paulb777 I think that’s possible to add a boolean for check if the Firestore db can be opened. Isn’t it? I’m thinking on checking if the user keychain value can be retrieved. In this way, if firebase change the query to set/get this value we don’t need to change a check logic, because the check logic is on your side and we use the boolean to retry it in a time or use no persistent storage.

CC: @unxavi

Thanks in advance

We’ve found a way to reproduce it on iPhone. You will need an iPhone and an Apple Watch.

1. Schedule an actionable notification in your app.
2. Reboot your phone and don’t unlock it.
3. Wait for the notification to come on Apple Watch.
4. Press a notification action button on Apple Watch. The app will crash.

When iPhone is rebooted you can’t press action buttons on notifications, but you can do it using Apple Watch.

Same on real iOS device…

Can this happen on real devices? if yes, how do I recover from it without asking users to delete/reinstall the app?

In my experience the “background” state reflected in Crashlytics isn’t terribly accurate. If you can observe some crashes in the background then it’s worth starting down the path of trying to figure that out. If, after fixing that there are still non-background crashes going on that would be a follow-up.

Firestore is incompatible with locked filesystems. In the future we’ll make this better by failing cleanly, but that will just push the failure out as an error out to your code–the failure will still be there.

So you have essentially two paths forward:

• Identify code paths in your system that might try to access Firestore in response to a push notification or background task and avoid making those calls, or
• Reduce the file protection level for Firestore’s backing data (as outlined in https://github.com/firebase/firebase-ios-sdk/issues/2846#issuecomment-484291699) (though note that since #4609, Firestore now stores its data in .applicationSupportDirectory, not .documentsDirectory). This is only valid if your local data is not sensitive.