InvalidKeyException: Error executing SQL: file is not a database

https://sentry.prod.mozaws.net/operations/firefox-beta/issues/7869497

Unclear what to do here, but crash should probably be avoided?

mozilla.appservices.logins.InvalidKeyException: Error executing SQL: file is not a database
    at mozilla.appservices.logins.rust.RustError.intoException(RustError.kt:13)
    at mozilla.appservices.logins.DatabaseLoginsStorage.unlock(DatabaseLoginsStorage.kt:14)
    at mozilla.components.service.sync.logins.LoginStorageConnection.init$service_sync_logins_release(SyncableLoginsStorage.kt:4)
    at mozilla.components.service.sync.logins.SyncableLoginsStorage$conn$2.invoke(SyncableLoginsStorage.kt:4)
    at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:6)
    at mozilla.components.service.sync.logins.SyncableLoginsStorage.getConn
    at mozilla.components.service.sync.logins.SyncableLoginsStorage.access$getConn$p(SyncableLoginsStorage.kt:1)
    at mozilla.components.service.sync.logins.SyncableLoginsStorage$getByBaseDomain$2.invokeSuspend(SyncableLoginsStorage.kt:3)
    at mozilla.components.service.sync.logins.SyncableLoginsStorage$getByBaseDomain$2.invoke
    at kotlin.jvm.internal.Intrinsics.startUndispatchedOrReturn(Intrinsics.java:2)
    at kotlin.jvm.internal.Intrinsics.withContext(Intrinsics.java:9)
    at mozilla.components.service.sync.logins.GeckoLoginStorageDelegate$onLoginFetch$1.invokeSuspend(GeckoLoginStorageDelegate.kt:8)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:2)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:19)
    at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:14)

┆Issue is synchronized with this Jira Task

This only showed up on the Beta 75 release.

Pretty steady volume of these crashes.

From a-s:

 * This error is emitted in two cases:
 *
 * 1. An incorrect key is used to to open the login database
 * 2. The file at the path specified is not a sqlite database.

From a discussion of "not a database" errors:

... developers may initially attempt to open a standard SQLite database and then call sqlite3_key 189 or PRAGMA key 131, thinking that SQLCipher will open the existing database and rewrite it using encryption. That is not possible, however, and such attempts will be met with a “file is encrypted or is not a database” error (code 26 / SQLITE_NOTADB).

The reason is that SQLCipher encryption works on a per-page basis for efficiency, and sqlite3_key and PRAGMA key can only be used:

    - when opening a brand new database (i.e. for the first time), or
    - when opening an already encrypted databases.

So a few things to verify here:

• can we ever attempt to open an existing non-encrypted database via the LoginsStorage backed by sqlcipher?
• can we ever loose our encryption keys? under what conditions?

this also happens when restoring Firefox Nightly's Data via Titanium Backup (to restore all the open tabs)

Firefox (normal) does not seem to have this problem

is there really no safe way to export and import all of your tabs from Firefox?

eg when transferring to another device or factory resetting

We noticed some new reports on newer versions.

My Firefox Nightly has been doing this for the past 7 days, out of the blue. I'm watching the Play Store up to ten times a day, and update as soon as I can, but to no avail thus far.

Is there anything I can do to make this error go away, without losing all my data? Or provide more info if needed?

Wiped all local data, reinstalled the app 12 days ago, and all was fine.. up until just now. It's crashing again, and this error is once again the cause.

We have several crash reports from Wolvic users due to this issue. We're trying to circumvent this issue with local hacks but it'd be awesome to get a proper fix from the android components. The problem is that we don't have a consistent way to reproduce this. The sqlite database somehow gets corrupted and then every attempt to access it (even for wiping it) results in an exception.

@svillar we haven't seen this crash in any of our apps since AC 75. I see that wolvic is still using AC 63 (we're at 107 now), so this looks to be fixed for us now.

I'm going to close this issue as fixed for now, but if you would like to discuss it more, we're migrating our issues to bugzilla where you can open a bug if you can reproduce this on the latest version of AC.