Key storage out of sync persistent toast silent failing

[MarcWadai]

Steps to reproduce

1. Where are you starting? What can you see?

I have read the parent issue #30444
A user in Tchap reported to have a persistent toast "key storage out of sync" and was persistent even after going through the process.
From the rageshake, we have those info :

cross_signing_master_privkey_cached: "true"
cross_signing_privkey_in_secret_storage: "true"
cross_signing_ready: "true"
cross_signing_self_signing_privkey_cached: "true"
cross_signing_user_signing_privkey_cached: "true" 
secret_storage_key_in_account: "true"
secret_storage_ready: "false"
session_backup_key_cached: "false"
session_backup_key_in_secret_storage: "true"
session_backup_key_well_formed: "false"
storageManager_persisted: "true"

I can see in the log that it is silently failing because of "Not saving backup key to secret storage: no backup key"

Outcome

What did you expect?

I expected the function saveBackupKeyToStorage() called by bootstrapSecretStorage() to throw an error so that it can be catch on the upper level SetupEncryptioToast, and display an error or other setps to follow accordingly

What happened instead?

Nothing happen, the method saveBackupKeyToStorage only return without throwing

Operating system

windows 10

Browser information

Firefox 128.0

URL for webapp

No response

Application version

Element 1.11.100 , Rust SDK 0.13.0 (f64839e), Vodozemac 0.9.0

Homeserver

No response

Will you send logs?

No

[t3chguy]

This sounds like either #30435 or #29141

@richvdh could you confirm?

[richvdh]

@andybalaam as maintainer please take a look

[andybalaam]

Here is what I think is happening:

Several places call accessSecretStorage but the most likely is SetupEncryptionToast.
exceptions coming from accessSecretStorage trigger a failure dialog that either tells them to reset their identity or to re-upload recovery data.
In our case I am guessing we want to reset identity because the backup key is somehow missing from their identity info.

accessSecretStorage calls doAccessSecretStorage()

doAccessSecretStorage calls bootstrapCrossSigning
with setupNewKeyBackup=false
if forceReset is false
and Client.secretStorage.hasKey() is true
Exceptions in doAccessSecretStorage are caught and rethrown

RustCrypto.bootstrapSecretStorage(.., setupNewKeyBackup) calls saveBackupKeyToStorage
if setupNewKeyBackup is false

RustCrypto.saveBackupKeyToStorage() fails in this way
if OlmMachine.getBackupKeys().decyptionKey is falsey

So if we throw from saveBackupKeyToStorage, we will probably show the failure dialog.

I'm going to see whether I can reproduce this problem in a test setup.

[andybalaam]

Here is how I managed to reproduce this:

1. Log in EW and enable recovery
2. In Storage -> Indexed DB -> matrix-js-sdk::matrix-sdk-crypto -> backup_keys delete key recovery_key_v1
3. Open a chat and type /devtools
4. Click Explore Account Data and click m.secret_storage.default_key to find out which key to delete
5. Edit m.secret_storage.key.THE_KEY_FROM_ABOVE, change its content to {} and click Send
6. Note that the "Your key storage is out of sync" toast appears
7. Click "Enter recovery key". Note that Sometimes clicking "Enter recovery key" takes me to "Change recovery key" #30978 happens.
8. Reset your recovery key
9. Note that the toast is still displayed.

When I updated the code to throw when it logged "Not saving backup key to secret storage: no backup key" I was dumped into the "Change recovery key" flow (which won't fix the problem). The first time I did this it showed me an error first, then dumped me there.

So it's not as simple as just throwing - we need to handle the error and instruct the user to reset their identity (or log out and in again?)

[andybalaam]

That's all the time I have to work on this as maintainer, so I'll put this in the Crypto backlog.

[richvdh]

I this is simply the same problem as #30435