#8917 Fix "Cannot find secrets in storage" error on Reset Everything

[christianrowlands]

Type of change

• Feature
• Bugfix
• Technical
• Other :

Content

Skip the SSSS integrity check when the user is in the "Reset everything" flow. The integrity check at SharedSecureStorageViewModel init validates that secrets exist in storage before proceeding but the "Reset everything" flow is specifically for when the user has lost access to their secrets. This creates a state where the reset fails because the very secrets the user wants to reset cannot be found.

The fix adds the same ResetAll step guard that already exists below for the key lookup (line 109), making the two checks consistent.

Motivation and context

Here is the issue this is fixing: #8917

Tests

• Step 1: Fresh account or account without SSSS setup
• Step 2: Trigger self-verification flow
• Step 3: Tap "Forgot or lost all recovery options? Reset everything"
• Step 4: Verify the reset confirmation screen appears instead of the error dialog

Tested devices

• Physical
• Emulator
• OS version(s): Android 16

Checklist

• Changes has been tested on an Android device or Android emulator with API 21
• UI change has been tested on both light and dark themes
• Accessibility has been taken into account. See https://github.com/element-hq/element-android/blob/develop/CONTRIBUTING.md#accessibility
• Pull request is based on the develop branch
• Pull request includes a new file under ./changelog.d. See https://github.com/element-hq/element-android/blob/develop/CONTRIBUTING.md#changelog
• Pull request includes screenshots or videos if containing UI changes
• Pull request includes a sign off
• You've made a self review of your PR
• If you have modified the screen flow, or added new screens to the application, you have updated the test UiAllScreensSanityTest.allScreensTest()

Signed-off-by: Christian Rowlands <craxiomdev [at] gmail.com>

[christianrowlands]

@bmarty , I have another bugfix PR for you if you have some time to review it. It is a one line fix, so hopefully an easy review.

[BillCarsonFr]

@christianrowlands Can you create a test in SharedSecureStorageViewModelTest ?
To reproduce the problem and show that the fix is working?

[CLAassistant]

All committers have signed the CLA.

[christianrowlands]

@BillCarsonFr , yep, I can do that. I added the test.

[BillCarsonFr]

@bmarty This is probably fixing the issue but I think there is a design problem.
It was introduced by #7721

The steps were initialy internal states, starting from a known point. It was triggering async things in the view model constructor.
Now the steps has been moved outside as a configurable thing. That's why there is this strange mix of step and requestType

Looks like we probably should have left the step as an internal thing and introduce a new RequestType. Or instead the SelfVerification Bottomsheet should directly call the navigator.open4SSetup(HARD_RESET)

... We won't probably spend time doing that