Fixing "key storage out of sync" fails silently if 4S and local device both lack backup key

[richvdh]

Steps to reproduce

STR are a bit convoluted, but empirically people have devices/accounts in this state, so:

1. Via Element dev tools, set m.megolm_backup.v1 account data to {}
2. Via browser dev tools, in matrix-js-sdk::matrix-sdk-crypto indexed db, in backup_keys store, delete recover_key_v1, then refresh.
   Alternatively, log in a new session, and verify with recovery key. (Either way, we end up with a device without the backup key.)
3. Observe:
4. Click "Enter recovery key"
5. Enter recovery key

Outcome

What did you expect?

Some sort of error report

What happened instead?

Nil, back to step 3

The logs contain:

W DeviceListener: check_<...>: 4S is missing secrets {"crossSigningReady":true,"secretStorageReady":false,"allCrossSigningSecretsCached":true,"isCurrentDeviceTrusted":true,"defaultKeyId":"<...>"}
I Opening toast with key 'setupencryption': title 'Your key storage is out of sync.'
...

# After entering recovery key:
D SecurityManager: accessSecretStorage: bootstrapSecretStorage
I Not saving backup key to secret storage: no backup key

[richvdh]

This is related to #29229; seems like we missed the backup key.

In an ideal world, we wouldn't even prompt the user to enter their recovery key in this scenario, but at the very least we should show the error when it inevitably fails.

[richvdh]

The best solution for a user who doesn't have their backup decryption key isn't actually a full reset; rather it's:

• turn off key storage
• turn it back on
• re-create recovery

... though maybe we should still take them through the reset flow, in case there are other things wrong with their account/device?

[krisavi]

So, you made update that messed up backup key or there even never was a backup key for some reason and now app is expecting it. Now in the UI you ask to enter recovery key and when it reports missing backup key in some dev tools area, then no normalized error message? Just keep the popup visible.

When people post issue with fitting title and description then it gets closed and some small link to this one that does not match with app behavior that they are most likely searching and reporting. Not all users go to dev tools. Why to get people from googling issue to solution when you could first give them the go-around. Users seeing that it keeps asking for recovery key don't even know about 4S and lack of backup key.

It is application issue if it silently fails. There should be patch done to at least instruct people that they are missing backup key and excuse because app development messed up at some point... And it should not be link to one issue that points to another issue that points to more issues that may or may not be even related.

[richvdh]

@krisavi I'm not entirely understanding you, but I guess your comment is related to my closing #30334, and I think your main point is that this issue is harder for users who encounter similar symptoms to find.

It's tricky for problems like this where there are multiple underlying causes which cause similar symptoms. As developers, we need to identify each individual cause and fix each one in turn. This issue is tracking one of those causes; #30439 is another. The instructions to open developer tools are not intended for users; rather, they are for an engineer to follow so that they can reproduce the problem that the user saw, and then fix it.

#30334 was a good issue report, but not very actionable for us as developers. Firstly, the OP had two different problems, which each need a separate solution; and secondly, as developers we need reliable steps to reproduce the problem before we can fix it. That is why I replaced it.

Nevertheless, I take your point that issues like this one are hard to find for users. Accordingly, I have opened #30444 which I hope will help.