Crashlytics report could not be enqueued to DataTransport after library upgrade

[mkocus]

[READ] Step 1: Are you in the right place?

Yes.

[REQUIRED] Step 2: Describe your environment

• Android Studio version: 2020.3.1 Patch 4
• Firebase Component: BoM 29.03 (crashlytics, config-ktx, dynamic-links-ktx, analytics-ktx, database-ktx, auth-ktx)
• Component version: as specified in BoM

[REQUIRED] Step 3: Describe the problem

Issue:

Firebase Crashlytics fails to send any crash, because it crashes internally. It happens after upgrading the library version and it does not fix by themself.

Steps to reproduce:

1. Have the library configuration as follow (config/analytics/dynamic-links probably not relevant, but leaving it for completeness):

implementation 'com.google.firebase:firebase-crashlytics:18.0.1'
implementation 'com.google.firebase:firebase-config-ktx:20.0.2'
implementation 'com.google.firebase:firebase-dynamic-links-ktx:19.1.1'
implementation 'com.google.firebase:firebase-analytics-ktx:18.0.1'

2. Upgrade to the BoM format as follow (again: config/analytics/dynamic-links/database/auth probably not relevant):

implementation platform('com.google.firebase:firebase-bom:29.0.3')
implementation 'com.google.firebase:firebase-crashlytics'
implementation 'com.google.firebase:firebase-config-ktx'
implementation 'com.google.firebase:firebase-dynamic-links-ktx'
implementation 'com.google.firebase:firebase-analytics-ktx'
implementation 'com.google.firebase:firebase-database-ktx'
implementation 'com.google.firebase:firebase-auth-ktx'

3. Crash the app using random fatal exception.

Error log:

The following warning is shown on logcat

2022-01-11 16:11:19.714 30893-30893/<our_package> I/FirebaseCrashlytics: Initializing Firebase Crashlytics 18.2.6 for <our_package>
2022-01-11 16:11:19.824 30893-30971/<our_package> V/DynamiteModule: Dynamite loader version >= 2, using loadModule2NoCrashUtils
2022-01-11 16:11:30.793 30893-30975/<our_package> E/SQLiteLog: (1) table log_event_dropped already exists
2022-01-11 16:11:30.796 30893-30975/<our_package> W/TransportRuntime: Error scheduling event table log_event_dropped already exists (code 1 SQLITE_ERROR): , while compiling: CREATE TABLE log_event_dropped (log_source VARCHAR(45) NOT NULL,reason INTEGER NOT NULL,events_dropped_count BIGINT NOT NULL,PRIMARY KEY(log_source, reason))
2022-01-11 16:11:30.799 30893-30972/<our_package> W/FirebaseCrashlytics: Crashlytics report could not be enqueued to DataTransport
    android.database.sqlite.SQLiteException: table log_event_dropped already exists (code 1 SQLITE_ERROR): , while compiling: CREATE TABLE log_event_dropped (log_source VARCHAR(45) NOT NULL,reason INTEGER NOT NULL,events_dropped_count BIGINT NOT NULL,PRIMARY KEY(log_source, reason))
        at android.database.sqlite.SQLiteConnection.nativePrepareStatement(Native Method)
        at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:903)
        at android.database.sqlite.SQLiteConnection.prepare(SQLiteConnection.java:514)
        at android.database.sqlite.SQLiteSession.prepare(SQLiteSession.java:588)
        at android.database.sqlite.SQLiteProgram.<init>(SQLiteProgram.java:58)
        at android.database.sqlite.SQLiteStatement.<init>(SQLiteStatement.java:31)
        at android.database.sqlite.SQLiteDatabase.executeSql(SQLiteDatabase.java:1770)
        at android.database.sqlite.SQLiteDatabase.execSQL(SQLiteDatabase.java:1698)
        at com.google.android.datatransport.runtime.scheduling.persistence.SchemaManager.lambda$static$4(SchemaManager.java:134)
        at com.google.android.datatransport.runtime.scheduling.persistence.-$$Lambda$SchemaManager$T1DaSoWWCWfbynOycgGeN7Vw-Vk.upgrade(Unknown Source:0)
        at com.google.android.datatransport.runtime.scheduling.persistence.SchemaManager.upgrade(SchemaManager.java:216)
        at com.google.android.datatransport.runtime.scheduling.persistence.SchemaManager.onUpgrade(SchemaManager.java:183)
        at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked(SQLiteOpenHelper.java:398)
        at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:298)
        at com.google.android.datatransport.runtime.scheduling.persistence.-$$Lambda$iV7-zVaNm3OzwRKNnkXrWOPrqvk.produce(Unknown Source:2)
        at com.google.android.datatransport.runtime.scheduling.persistence.SQLiteEventStore.retryIfDbLocked(SQLiteEventStore.java:568)
        at com.google.android.datatransport.runtime.scheduling.persistence.SQLiteEventStore.getDb(SQLiteEventStore.java:94)
        at com.google.android.datatransport.runtime.scheduling.persistence.SQLiteEventStore.runCriticalSection(SQLiteEventStore.java:751)
        at com.google.android.datatransport.runtime.scheduling.DefaultScheduler.lambda$schedule$1$DefaultScheduler(DefaultScheduler.java:81)
        at com.google.android.datatransport.runtime.scheduling.-$$Lambda$DefaultScheduler$TUAu_XOWDlEdt54QDWOOZf2JNr8.run(Unknown Source:8)
        at com.google.android.datatransport.runtime.SafeLoggingExecutor$SafeLoggingRunnable.run(SafeLoggingExecutor.java:47)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.lang.Thread.run(Thread.java:764)
2022-01-11 16:19:11.412 4346-5120/? I/cr_CastCrashUploader: Remove crash dumps

It seems that crashlytics cannot handle gracefully situation when some table already exists - and it tries to create it and fails.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[argzdev]

Hi @mkocus, thanks for the report.

I tried to repro the issue but wasn't able to.

Here's the steps I did:

1. Create a clean project with your first library configuration, add the project to Firebase console
2. Run the app, crash the app, and see that the crash is visible in the Firebase console
3. Change the library configuration with the BoM format
4. Run the app, crash the app

After that, I didn't encounter the issue, am I missing something?
May I ask if you were able to repro this issue consistently with every new project build?

I think the fix for this could be like CREATE TABLE IF NOT EXISTS instead of just CREATE TABLE in our Firebase SchemaManager.java where log_event_dropped is being created, but this could depend if the table db hasn't changed its schema format from the previous versions.

[mkocus]

Thanks @argzdev for fast response.

I've again tried to replicate it by constructing minimum replicable project example and environment and failed.
It seems that this is not directly related to updating from one version to another - but rather some strange state.

As for your issue: #3304
i would rather propose to DROP TABLE IF EXIST instead (before creating table) - as this will be more future proof.

[mkocus]

Yet another update - I can replicate it again, but only on our project, even after clearing app data.

For know we will probably use version <18.2.4 and wait to fix to be deployed.

[argzdev]

Thanks for the feedback, @mkocus. I think this only happens when the migration/upgrade of version somewhat stops or fails halfway, thus the table is created and the issue occurs, which makes this issue difficult to reproduce.

With that said, thanks for the proposed solution. I've made the change as needed, but I'll ask an engineer to take a closer look at it, if whether it's clear for merging or needs update.

[argzdev]

Hi @mkocus, the pull request has now been merged. Although I can't specify a timeline when the next release is, but you can keep an eye out on our release notes. With that said, I'll close this issue now.