Skip to content

Route existing backups to recovery key entry - #7320

Closed
pi0n00r wants to merge 1 commit into
element-hq:developfrom
pi0n00r:pi0n00r/fix-recovery-key-routing
Closed

Route existing backups to recovery key entry#7320
pi0n00r wants to merge 1 commit into
element-hq:developfrom
pi0n00r:pi0n00r/fix-recovery-key-routing

Conversation

@pi0n00r

@pi0n00r pi0n00r commented Aug 4, 2026

Copy link
Copy Markdown

Content

  • When a server backup exists while local recovery is DISABLED, show and route to the existing enter-recovery-key flow instead of offering to set up new recovery.
  • Map RustRecoveryException.Import through the application recovery-exception boundary instead of treating the import failure as a successful recovery.
  • Add focused state, view-routing, and exception-mapping tests.

Motivation and context

Users with an existing server backup can reach a locally disabled recovery state. Offering setup-new recovery in that state sends them down the wrong path; the existing key-entry flow is the appropriate route.

Separately, an SDK room-key import failure must remain a failure so the UI can report it rather than proceeding as though recovery succeeded.

Related symptom report: #7283. This change may improve routing and import-error reporting for overlapping “key storage out of sync” cases, but it does not claim to fix that issue's reported incorrect-key cause or every historical Megolm restore failure.

Screenshots / GIFs

Not provided. The change reuses the existing recovery-key confirmation content and flow.

Tests

Focused tests were added for the new routing decision, its click target, and import-exception mapping.

Local tests were not run because the required Android toolchain was unavailable. GitHub-hosted PR CI is requested as the test substrate.

Tested devices

  • Physical
  • Emulator
  • OS version(s): Not tested locally

Checklist

  • I am aware of the etiquette.
  • This PR was made with the help of AI:
    • Yes. In this case, please request a review by Copilot.
    • No.
  • Changes have been tested on an Android device or Android emulator with API 24
  • UI change has been tested on both light and dark themes
  • Accessibility has been taken into account. See https://github.com/element-hq/element-x-android/blob/develop/CONTRIBUTING.md#accessibility
  • Pull request is based on the develop branch
  • Pull request title will be used in the release note, it clearly defines what will change for the user
  • Pull request includes screenshots or videos if containing UI changes
  • You've made a self review of your PR

Offer the existing recovery-key confirmation flow when a server backup is present even if local recovery is disabled. Propagate Rust import failures through the application recovery exception boundary instead of treating them as success.
@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@github-actions github-actions Bot added the Z-Community-PR Issue is solved by a community member's PR label Aug 4, 2026
@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Thank you for your contribution! Here are a few things to check in the PR to ensure it's reviewed as quickly as possible:

  • If your pull request adds a feature or modifies the UI, this should have an equivalent pull request in the Element X iOS repo unless it only affects an Android-only behaviour or is behind a disabled feature flag, since we need parity in both clients to consider a feature done. It will also need to be approved by our product and design teams before being merged, so it's usually a good idea to discuss the changes in a Github issue first and then start working on them once the approach has been validated.
  • Your branch should be based on origin/develop, at least when it was created.
  • The title of the PR will be used for release notes, so it needs to describe the change visible to the user.
  • The test pass locally running ./gradlew test.
  • The code quality check suite pass locally running ./gradlew runQualityChecks.
  • If you modified anything related to the UI, including previews, you'll have to run the Record screenshots GH action in your forked repo: that will generate compatible new screenshots. However, given Github Actions limitations, it will prevent the CI from running temporarily, until you upload a new commit after that one. To do so, just pull the latest changes and push an empty commit.

@pi0n00r

pi0n00r commented Aug 7, 2026

Copy link
Copy Markdown
Author

Thank you for considering this contribution. We will not sign the Element CLA because its commercial-relicensing terms fall outside our contribution policy. We are therefore withdrawing the contribution while preserving the patch in our fork. Element is welcome to implement the remedy independently.

@pi0n00r pi0n00r closed this Aug 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Z-Community-PR Issue is solved by a community member's PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants