1258596 - `PushDB` won't initialize if there are backward-incompatible changes to the IDB schema

Status: RESOLVED WORKSFORME

(Core :: DOM: Push Subscriptions, defect, P3)

Description

[Lina Butler (ex-Mozilla)]

:markh encountered bug 1258595 with a test profile the other day. The likely culprit is IndexedDB corruption caused by using the profile with multiple release channels (bug 1236557):

> 12:43:28.935 Quota 'resource' is not a valid schema!: ActorsParent.cpp:63661(unknown)
> 12:43:28.935 IndexedDB UnknownErr: ActorsParent.cpp:5841(unknown)

Although downgrading profiles isn't supported, Push could definitely be more resilient in the face of IDB errors. Bug 1258595 addresses the deadlock on startup, but still prevents callers from using Push: all calls to `subscribe`, `getSubscription`, and `unsubscribe` via the XPCOM and DOM APIs will reject with errors.

I'm wondering if we can use https://dxr.mozilla.org/mozilla-central/rev/4037eb98974db1b1e0b5012c8a7f3a36428eaa11/dom/quota/nsIQuotaManagerService.idl#48-50 to reset IDB if we encounter "unknown errors" like that. `nsIQuotaManagerService.clearStoragesForPrincipal(Services.scriptSecurityManager.getSystemPrincipal(), "persistent")` seems like it would do the trick, but there are some questions to consider:

1. Will this drop all IDB databases created by privileged code? (Probably not a concern on Desktop. I know B2G uses IDB in other JS-implemented Web APIs, but we don't have to worry about those here).

2. Will this actually solve the corruption, or is it happening at a lower level in SQLite?

3. Should we move away from using IDB to flat files instead? This would also fix storage invalidation via `nsIQuotaManagerService.clear()`, which is blocking bug 1185716. But I'd prefer not to rewrite PushDB.jsm if there's an easier answer.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

There's now a profile mechanism in place to prevent attempting to use a profile from the future, as well as profile-per-channel mechanisms to help avoid accidentally getting into a situation like that, so I am going to resolve this WFM. That said, bug 1759711 can potentially help with this by just automatically deleting the database if we expand the scope of what it means for a database to be corrupt. (And that bug is appropriate an IDB bug, not a push bug; it's not push's problem.)

As Jari pointed out in the triage meeting, we do have some corruption handling when opening databases, but unfortunately it seems that the schema being from the future is not treated as corruption. Specifically, here we try and open the database and our use of QM_OR_ELSE_WARN_IF uses a predicate that treats corrupt databases specially with the fallback returning a null connection which then results in us trying to delete the database file and if that works we go and try and open/create the database again. But it's only after that that we load the schema version and we'll then bail if the schema is from the future.