"Unable to restore session" error due due to half-initialised legacy indexeddb crypto store

[richvdh]

We've seen a number of reports from users who are suddenly unable to load their Element-Web (or Desktop) sessions due to an "Unable to restore session" error.

The common theme appears to be that they have a half-initialised matrix-js-sdk:crypto indexeddb store. This makes the Rust crypto code think that it has to do a migration, but there is no actual data to migrate, so it fails.

It's unclear to me what, exactly, is causing the matrix-js-sdk:crypto indexeddb store to be created. I think the most likely cause is something calling matrix.createClient or matrix.createRoomWidgetClient without an explicit cryptoStore; in that case amendClientOpts uses the default cryptoStoreFactory which creates an empty matrix-js-sdk:crypto indexeddb store. [Ironically all this code will go away once we finally rip out the legacy crypto code (#26922), but for now, we're a bit stuck with it.]

What, exactly, is calling matrix.createClient or matrix.createRoomWidgetClient without a crypto store is unknown to me. There are lots of such calls in the react SDK, but they all seem to relate to auth operations, or possibly stuff to do with the ModuleApi, which I don't see much evidence of in the rageshakes. Alternatively, it might be a completely different application on the same domain which happens to use the js-sdk.

I think the best course of action here is to be more conservative in what triggers a migration. In particular, if there is no account.- key in the store, then we should not attempt a migration.

[richvdh]

I think this should be a blocker for further rollout of Element-R