Skip to content

Closing app right after onboarding interrupts extra accounts loading #874

Description

@leofelix077

Local issue only, reimporting the account will make the accounts load

Right after onboarding, there is a few seconds in which the user is inside the HomeScreen, but the extra user accounts are being loaded in the background

If the user closes the app while the accounts are being imported and not finished, the import gets interrupted and is not retried, so a wallet re-import is needed

It is a 2-3s (usually, on a normal connection) window that accounts finish loading and the app needs to be fully closed, so a slow internet might be needed to consistently reproduce

Steps:

  1. Pick an account with multiple wallets
  2. Finish onboarding
  3. Close the app as soon as user gets on HomeScreen
  4. Re-open the app
  5. Only account 1 is loaded (Potential accounts 2-5 are not loaded) ❌ - Re-opening the app will not resume the interrupted process
  6. Select "Create New Wallet"
  7. Account 6 gets loaded ❌ - Should load account 2
  8. Accounts 2-5 (potential) are not accessible without a re-import

Potential fixes (AI enhanced)

  • Reconcile orphan keychain keys at sign-in. Walk the keychain at the end of a successful signIn, decrypt any keys that aren't in the account list, and append them. Closes the "accounts are lost forever after a partial import" tail in one change. Requires the password in scope, so it has to live on the sign-in path rather than at app open.
  • Anchor the next-HD-index calculation on the mnemonic, not the account-list length. "Create new wallet" should derive keypairs from HD index 0 upward and pick the smallest publicKey that isn't already known. This is robust against any past or future drift, and it also fixes the existing bug where deleting a middle account causes the next "Create" to silently re-use that slot.
  • Make the bulk-import flow atomic-ish. Either reverse the write order (placeholder entries to the account list first, keychain writes after) so any kill leaves a coherent intent in AsyncStorage, or add a "pending bulk import" flag that gets set at the start and cleared at the end. On app open, if the flag is still set, re-run the discovery idempotently. This is the only path that fully closes the kill-mid-write window, but it's the largest design change.
  • Decouple the display name from "list length + 1". Either tie the name to the HD index used, or maintain a stable counter that doesn't get re-used when middle accounts are deleted. Doesn't fix the underlying data integrity issue but removes the user-facing "Account 6 instead of Account 2" confusion.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions