NSInternalInconsistencyException crash in FIRMessagingRmqManager openDatabase persists after #15573 fix

[MaayanLoop]

Description

We're experiencing a startup crash in [FIRMessagingRmqManager openDatabase] that throws NSInternalInconsistencyException. This persists on Firebase 12.9.0, which includes the corrupt database recovery logic from #15573 and #15678.

The recovery logic added in 12.8.0 only handles SQLITE_CANTOPEN errors, but our crash throws NSInternalInconsistencyException — a different failure mode that bypasses the recovery path.

Environment

• Firebase SDK: 12.9.0 (via SPM)
• App version: 1.1.1380
• Crashlytics issue: 716c82e1d34d6c497a8e69610153c6bd
• Affected iOS versions: iOS 18
• Other database SDKs: Realm (but NOT initialized at time of crash)

Crash Stack Trace

Fatal Exception: NSInternalInconsistencyException

com.apple.main-thread:
0  ...
5  Zenzap  -[FIRMessagingRmqManager loadInitialOutgoingPersistentId] + 178 (FIRMessagingRmqManager.m:178)
6  Zenzap  -[FIRMessagingRmqManager loadRmqId] + 154 (FIRMessagingRmqManager.m:154)
7  Zenzap  -[FIRMessaging setupRmqManager] + 309 (FIRMessaging.m:309)
8  Zenzap  -[FIRMessaging start] + 285 (FIRMessaging.m:285)
9  Zenzap  +[FIRMessaging componentsToRegister]_block_invoke + 176 (FIRMessaging.m:176)
...
17 Zenzap  AppInitManager.doOnFirstApplicationLaunch(application:appDelegate:) + 28

Crashed thread (exception recording):
...
15 Zenzap  __38-[FIRMessagingRmqManager openDatabase]_block_invoke + 554 (FIRMessagingRmqManager.m:554)

Key Observations

1. Crash is launch-blocking — the user cannot open the app until reinstalling
2. Same user crashed repeatedly — two sessions on consecutive days (Feb 28 & Mar 1, 2026), confirming the corrupted state persists across launches
3. Realm is NOT involved — our Realm database is initialized much later in the app lifecycle, well after Firebase. The crash occurs during FirebaseConfiguration.configure() before any Realm access
4. Recovery logic doesn't trigger — the fix in [FCM] Recovery logic for a corrupt database #15573 catches SQLITE_CANTOPEN, but this crash throws NSInternalInconsistencyException, which appears to be a different error path in openDatabase (line 554) that isn't covered

Expected Behavior

The recovery logic should also handle NSInternalInconsistencyException from openDatabase by deleting and recreating the database, similar to the SQLITE_CANTOPEN recovery.

Related Issues

• iOS App Crashed on app launch - Firebase SQL file not found #14880 (closed, but this crash persists)
• [FCM] Recovery logic for a corrupt database #15573 (recovery logic PR)
• [FCM] Narrower database open recovery logic #15678 (narrowed recovery to SQLITE_CANTOPEN)

[leojaygoogle]

Hi, could you share the full stack trace, including the error message? We're particularly interested in the SQLite error.
It would be great if you could provide a minimal project repository to reproduce this issue.

[MaayanLoop]

For this crash the error is:

Fatal Exception: NSInternalInconsistencyException
Could not create RMQ database at path /var/mobile/Containers/Data/PluginKitPlugin/6DCF02E0-01A7-4668-9C6F-07464074081B/Library/Application Support/Google/FirebaseMessaging/rmq2.sqlite, error: 14 - unable to open database file

The relevant stacks tmo are:

[MaayanLoop]

It also happens in the main app (not only notification extension).

[leojaygoogle]

Thanks for the detailed info! it's very helpful.

Could not create RMQ database at path /var/mobile/Containers/Data/PluginKitPlugin/6DCF02E0-01A7-4668-9C6F-07464074081B/Library/Application Support/Google/FirebaseMessaging/rmq2.sqlite, error: 14 - unable to open database file

This error message shows that:

1. The error code was indeed SQLITE_CANTOPEN: error: 14 - unable to open database file
2. The Could not create RMQ database error message seems to suggest that the SDK version you are using doesn't include [FCM] Recovery logic for a corrupt database #15573 because we changed the wording from Could not create RMQ database to Could not open RMQ database in that PR.

Could you please update the SDK and try again?