Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EW: Inform users when fixing "key storage out of sync" fails #29229

Open
Tracked by #2700
mxandreas opened this issue Feb 7, 2025 · 4 comments
Open
Tracked by #2700

EW: Inform users when fixing "key storage out of sync" fails #29229

mxandreas opened this issue Feb 7, 2025 · 4 comments
Labels
A-E2EE A-E2EE-Cross-Signing A-Error-Message O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Impairs non-critical functionality or suitable workarounds exist T-User Story Team: Crypto

Comments

@mxandreas
Copy link

mxandreas commented Feb 7, 2025

Problem

In case the user is notified about their key storage is out of sync (their device is missing a secret), they have the option to enter their recovery key and try to fix the issue by retrieving the missing secret from key storage. However, it could happen that the key storage also does not have the secret so the user will remain in the key storage is out of sync broken state.

The issue is that currently the user is not informed at all that fixing the issue failed, and that they need to reset their identity to set it up correctly.

Designs

Note that the designs of the entire key storage is out of sync journey assume that the recovery key entry modal is modernized and the entire flow is embedded into the Settings overlay. This would be desired, but it is acceptable if the recovery key entry is present as modal after which user lands in the Settings overlay where they are told about the need to reset.

@mxandreas mxandreas changed the title EW: Tell users that they have to do a reset when fixing key storage fails EW: Inform users when fixing "key storage out of sync" fails Feb 7, 2025
@richvdh richvdh transferred this issue from element-hq/element-meta Feb 10, 2025
@dosubot dosubot bot added A-E2EE A-Error-Message O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Impairs non-critical functionality or suitable workarounds exist labels Feb 10, 2025
@richvdh
Copy link
Member

richvdh commented Feb 10, 2025

There are two and a half potential failure modes:

@richvdh
Copy link
Member

richvdh commented Feb 10, 2025

I think this is the same as #27808 and #27252. At the very least, I would expect to be able to close those issues after fixing this one.

@mxandreas
Copy link
Author

I think this is the same as #27808 and #27252. At the very least, I would expect to be able to close those issues after fixing this one.

@richvdh I see how these are related issues but I am wondering what does it change regarding this issue? Are you saying that we do not need to tell the user that fixing failed, because by fixing some bugs we can make it succeed in 99.999% of the time?

@richvdh
Copy link
Member

richvdh commented Feb 11, 2025

No, I don't think it changes anything here. I'm just adding cross-references between similar issues, to help us navigate the issue tracker, and (hopefully) remember to close existing issues when they are fixed.

Those other issues amount to much the same thing: "In situation XYZ, attempting to set up the local device using recovery fails silently. We should let the user know that it didn't work."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE A-E2EE-Cross-Signing A-Error-Message O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Impairs non-critical functionality or suitable workarounds exist T-User Story Team: Crypto
Projects
None yet
Development

No branches or pull requests

2 participants