Firebase-android-sdk: Runtime SQLite Table crash after upgrading Core and Messaging Versions

[froriz5]

[REQUIRED] Step 2: Describe your environment

• Android Studio version: 3.6.3
• Firebase Component: Core & Messaging
• Component version: Core 17.4.1 & Messaging 20.1.7

[REQUIRED] Step 3: Describe the problem

Steps to reproduce:

We recently updated our Firebase Messaging version from 19.0.1 to 20.1.7 and Firebase Core from 17.0.0 to 17.4.1 .

After doing so, when we relaunched our app, a crash surfaced related to the package: com.google.android.datatransport

Here is the stack trace:

Process: com.sproutsocial.android.debug, PID: 11938
    android.database.sqlite.SQLiteException: table event_payloads already exists (code 1 SQLITE_ERROR): , while compiling: CREATE TABLE event_payloads (sequence_num INTEGER NOT NULL, event_id INTEGER NOT NULL, bytes BLOB NOT NULL,FOREIGN KEY (event_id) REFERENCES events(_id) ON DELETE CASCADE,PRIMARY KEY (sequence_num, event_id))
        at android.database.sqlite.SQLiteConnection.nativePrepareStatement(Native Method)
        at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:986)
        at android.database.sqlite.SQLiteConnection.prepare(SQLiteConnection.java:593)
        at android.database.sqlite.SQLiteSession.prepare(SQLiteSession.java:590)
        at android.database.sqlite.SQLiteProgram.<init>(SQLiteProgram.java:61)
        at android.database.sqlite.SQLiteStatement.<init>(SQLiteStatement.java:33)
        at android.database.sqlite.SQLiteDatabase.executeSql(SQLiteDatabase.java:1805)
        at android.database.sqlite.SQLiteDatabase.execSQL(SQLiteDatabase.java:1733)
        at com.google.android.datatransport.runtime.scheduling.persistence.SchemaManager.lambda$static$3(com.google.android.datatransport:transport-runtime@@2.2.1:109)
        at com.google.android.datatransport.runtime.scheduling.persistence.SchemaManager$$Lambda$4.upgrade(Unknown Source:0)
        at com.google.android.datatransport.runtime.scheduling.persistence.SchemaManager.upgrade(com.google.android.datatransport:transport-runtime@@2.2.1:182)
        at com.google.android.datatransport.runtime.scheduling.persistence.SchemaManager.onUpgrade(com.google.android.datatransport:transport-runtime@@2.2.1:152)
        at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked(SQLiteOpenHelper.java:417)
        at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:317)
        at com.google.android.datatransport.runtime.scheduling.persistence.SQLiteEventStore$$Lambda$1.produce(Unknown Source:2)
        at com.google.android.datatransport.runtime.scheduling.persistence.SQLiteEventStore.retryIfDbLocked(com.google.android.datatransport:transport-runtime@@2.2.1:517)
        at com.google.android.datatransport.runtime.scheduling.persistence.SQLiteEventStore.getDb(com.google.android.datatransport:transport-runtime@@2.2.1:82)
        at com.google.android.datatransport.runtime.scheduling.persistence.SQLiteEventStore.runCriticalSection(com.google.android.datatransport:transport-runtime@@2.2.1:549)
        at com.google.android.datatransport.runtime.scheduling.jobscheduling.WorkInitializer.lambda$ensureContextsScheduled$1(com.google.android.datatransport:transport-runtime@@2.2.1:54)
        at com.google.android.datatransport.runtime.scheduling.jobscheduling.WorkInitializer$$Lambda$1.run(Unknown Source:2)
        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:919)

I could reproduce it by having a version of the app, which had the old firebase version installed, and then upgrading the apk to the app with the updated firebase versions.

It's unclear if this crash and upgrade of Firebase Versions are related.

[ashwinraghav]

Thanks for the report.
I've not been able to repro the issue you are describing. I suspect there are other Firebase products you are using? If you can share your dependencies tree ./gradlew :app:dependencies, before and after the migration steps, that might help us track this down better.

[ashwinraghav]

We seem to have a bug @https://github.com/firebase/firebase-android-sdk/blob/4498fccb497a897f2832599c8db42cb34abc5ce9/transport/transport-runtime/src/main/java/com/google/android/datatransport/runtime/scheduling/persistence/SchemaManager.java#L76 where going back and forth between version 4 of the database and any other older versions would lead to this error. I've been able to simulate the errors on PR https://github.com/firebase/firebase-android-sdk/pull/1548.

I suspect you have have upgraded -> downgraded -> upgraded any/all of these Firebase SDKs - Firebase In App Messaging, Crashlytics, Messaging or MLKit.

[froriz5]

Yeah, I think it's likely I did do a upgraded -> downgraded -> upgraded, when I was doing some verification.

We can likely mark this as a duplicate issue and close it then?

[ashwinraghav]

If you have seen this issue only during development, and have not shipped versions of your app that go back and forth between versions, it should be safe to roll forward with your app pointing to the latest versions.
If your users are actually seeing these crashes as a result of releases of your app having such version fluidity of firebase dependencies, Have your users delete their local state (cache and disk) in the app. Other programmatic fixes such as deleting the table in your app could be error prone in the long term.
Sry bout the pain. We're trying to support this version fluidity a bit better going forward!

[ashwinraghav]

Yeah, I think it's likely I did do a upgraded -> downgraded -> upgraded, when I was doing some verification.

We can likely mark this as a duplicate issue and close it then?

SG. Thank you

[smuldr]

This looks very similar to #1531

[marius-bardan]

seeing this as well. app is crashing in a loop. only workaround is uninstall or clearing data.

We're using both firebase-messaging:20.1.6 and firebase-crashlytics:17.0.0, so I'm not sure which one is the culprit as both seem to link against 'transport-runtime'.
We're using android gradle plugin version 3.5.3.