Wallet Recovery via Encrypted File Stuck on "Your Wallet is Ready!" Screen

[Ivanlomoljo26]

I attempted to retrieve my wallet using an encrypted file, but it remained stuck on the "Your wallet is ready!" page.
See the screenshot

[Ivanlomoljo26]

Cc @WiktorStarczewski @0xnullifier

Note: I have yet to double-check this in my full console output or instrument the code. For now, it isn't possible because I got stuck on this issue #200; hence, I can't proceed with reproducing the steps. WIll provide more details once the blocking issue gets fixed.

Summary

Restoring a wallet from an encrypted .json file on the password-protected path leaves the user permanently stuck on the "Your wallet is ready!" screen. Tapping Get started fires onAction({ id: 'confirmation' }) which calls register() → importWalletFromClient → backend registerImportedWallet → Vault.spawnFromMidenClient; this path throws (wrapped as PublicError by withError('Failed to spawn from miden client', …)), but Welcome's catch handler only updates user-visible error state when password === '__HARDWARE_ONLY__'. Password-protected restores therefore produce a console.error + silent spinner reset, with zero UI feedback and the same "Your wallet is ready!" button re-enabled for a second identical silent failure. Reproduced on main (commit 284e99e, wallet v1.14.2). The same gap also exists in the ForgotPassword flow, which routes through the same call.

Symptoms

User-visible: the Get started button shows a brief loading spinner, the spinner clears, no error text or dialog appears, the same "Your wallet is ready!" screen remains on-screen. Tapping again reproduces the same silent result. The only evidence that registration actually failed is in the devtools console — which a normal user never opens.

The reporter's screenshot attached to the issue shows two identical [Welcome] Confirmation flow failed: console.error lines originating from fullpage.tsx, matching a user retry after seeing no feedback. This is empirical confirmation that the catch branch ran (twice), not a hanging promise.

Persistence scope: affects every encrypted-file restore attempt on Chrome / Firefox extension (any context where the user sets a password rather than using biometric/hardware protection). Does not affect the hardware-only mobile/desktop path, which surfaces errors via biometricError + biometricAttempts.

Reproduction steps

1. Fresh install of the wallet extension (no vault yet). Launch → Welcome screen.
2. Tap I already have a wallet → Restore from encrypted file.
3. Drop in a valid .json wallet export, enter the file's decryption password, tap Import. importStore(midenClientDbContent, 'miden-wallet') and importDb(walletDbContent) succeed; navigation advances to #create-password.
4. Enter a new app password + confirmation, tap Continue. Navigation advances to #confirmation ("Your wallet is ready!" screen).
5. Tap Get started. Spinner appears, then disappears. No error, no navigation.

• Expected: Either registration succeeds and the app navigates to the home screen, or the user sees a visible error ("Failed to import wallet" or similar) with an actionable next step (retry / back to import screen).
• Actual: Spinner disappears, no UI feedback. The user is stuck. Tapping Get started again reproduces the same silent failure — exactly the two-line Confirmation flow failed trail visible in the screenshot.
• Reproduction rate: ~100% on any encrypted-file restore that triggers a throw in Vault.spawnFromMidenClient when the user has chosen password protection (i.e. password !== '__HARDWARE_ONLY__').

Root cause (1 location)

src/app/pages/Welcome.tsx#L214-L235

case 'confirmation':
  try {
    setIsLoading(true);
    setBiometricError(null);
    await register();                         // importWalletFromClient → Vault.spawnFromMidenClient
    await waitForReadyState(syncFromBackend);
    setIsLoading(false);
    navigate('/');
  } catch (error) {
    console.error('[Welcome] Confirmation flow failed:', error);
    setIsLoading(false);
    if (password === '__HARDWARE_ONLY__') {   // ← guard excludes password-protected restores
      const newAttempts = biometricAttempts + 1;
      setBiometricAttempts(newAttempts);
      setBiometricError(error instanceof Error ? error.message : 'Biometric authentication failed');
    }
  }
  break;

Error state (biometricError, biometricAttempts) is only populated for the hardware-only sentinel. Password-protected restores — which is the default path on extension — hit the silent branch: console error, spinner reset, no UI state change. The Confirmation screen's render gate Confirmation.tsx#L30 is const hasError = biometricError && biometricAttempts > 0, so without either flag being set the red error text is never shown and the Get started button simply re-enables — indistinguishable from a first-time load.

Receipts (evidence chain)

Signal	Source	What it proves
Catch branch only surfaces errors behind hardware-only sentinel	Welcome.tsx#L225-L234	The password-protected file-import path produces no user-visible error — UI gap is real and localized to this predicate.
Confirmation renderer requires both flags truthy to show any error	Confirmation.tsx#L30-L53,L73-L80	Without biometricError being set, no red text appears; the button just swaps from isLoading back to "Get started", matching the reporter's symptom exactly.
spawnFromMidenClient failures genuinely propagate as PublicError	vault.ts#L291-L292 — return withError('Failed to spawn from miden client', async () => { ... })	Whatever throws inside the vault spawn (a plausible candidate is vault.ts#L353 dereferencing newAccounts[0]!.publicKey with a non-null assertion and no length check) does reach the Welcome catch — errors are not being swallowed deeper. The catch handler is definitively the place responsible for surfacing them.
Reporter's screenshot shows two silent Confirmation flow failed console errors	Screenshot attached to issue #136 — devtools panel shows two [Welcome] Confirmation flow failed: lines originating from fullpage.tsx, and the Get started CTA still rendered	Empirical confirmation: the catch branch ran (hits console.error on line 226), cleared loading, and surfaced no UI feedback — prompting the user to tap again and produce the second identical error.
Same gap exists in the forgot-password flow	ForgotPassword.tsx#L40-L44 — importWalletFromClient wrapped in a try { … } catch (e) { console.error(e); } that surfaces nothing	The pattern is not isolated; the fix should be applied symmetrically to both onboarding entry points.
Historical context: error-swallowing pattern has persisted across refactors	git show 495673e ("fix: add wallet accounts to the encrypted file, add secret keys when importing from file") — prior version wrapped importWalletFromClient in an inner try/catch that also swallowed the error entirely	Not a recent regression; the same silencing has existed in different forms for over a year.

Suggested direction

Lift the error-display path out from under the password === '__HARDWARE_ONLY__' guard so the password-protected branch also gets a visible error. The simplest shape: always populate a generic confirmationError state inside the catch (rename biometricError or add a sibling), and render it unconditionally above the button in Confirmation.tsx, keeping the biometric-attempts counter as a hardware-only specialization. Because ForgotPassword.tsx#L40-L44 uses the same importWalletFromClient shape with its own silent console.error(e) catch, apply the same fix symmetrically so a user hitting a failed restore during the forgot-password flow gets the same feedback. A secondary hardening worth folding in: guard against re-submit while a previous failure is still on the floor — a hasFailedOnce flag or a disabled-on-error state on Get started would prevent the duplicate-console-error trail seen in the reporter's screenshot, which indicates the user tapping a re-enabled button after no visible feedback.