fix: handle emptyMainAccount for revoked key during multi-restore

[lmcmz]

Summary

• When a user's on-chain key is revoked, keyIndexer returns no account for the public key, causing WalletError.emptyMainAccount to be thrown
• RestoreMultiAccountViewModel did not catch this error, so it fell into the generic error handler and showed a confusing error message
• Added a catch for emptyMainAccount that follows the same recovery path as noActiveKeys: cleanup revoked account data and add a new key

Root Cause

The validation flow in WalletManager+KeyValidation:

1. validateKeyProvider fetches account using the revoked key's public key
2. keyIndexer returns empty account list (revoked key is no longer associated)
3. Guard at line 114 fails → records as providerWithoutAccount (instead of detecting revoked state)
4. buildFinalResult Priority 1 returns .providerWithoutAccount
5. restoreLogin throws WalletError.emptyMainAccount
6. Not caught by RestoreMultiAccountViewModel → generic error

Test plan

• Revoke a user's on-chain key, then try to restore/switch to that account
• Verify the app cleans up and triggers new key creation instead of showing an error

🤖 Generated with Claude Code

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[github-actions]

PR Summary

Added error handling for WalletError.emptyMainAccount in RestoreMultiAccountViewModel to properly handle revoked on-chain keys. When a user's key is revoked, the keyIndexer returns no account for the public key, causing emptyMainAccount to be thrown. Previously, this error was not caught and fell into the generic error handler, showing a confusing error message. The fix adds a catch block that follows the same recovery path as noActiveKeys: dismissing the loading HUD, cleaning up the revoked account data via cleanupRevokedAccount, and triggering new key creation via addKey.

Changes

File	Summary
FRW/Modules/MultiRestore/ViewModel/RestoreMultiAccountViewModel.swift	Added a new catch block for WalletError.emptyMainAccount that logs a warning, dismisses the loading HUD, cleans up the revoked account using cleanupRevokedAccount, and calls addKey to create a new key. This mirrors the existing noActiveKeys error handling path.

---

autogenerated by presubmit.ai

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[github-actions]

✅ LGTM!

Review Summary

Commits Considered (1)

• 6402384: fix: handle emptyMainAccount error for revoked key during multi-restore

When a user's on-chain key is revoked, keyIndexer returns no account for
the public key. This causes validateKeyProvider to classify it as
"provider without account" instead of detecting the revoked state.
restoreLogin then throws WalletError.emptyMainAccount, which was not
caught by RestoreMultiAccountViewModel, falling into the generic error
handler.

Add a catch for WalletError.emptyMainAccount that follows the same
recovery path as noActiveKeys: cleanup the revoked account and add a
new key.

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

Files Processed (1)

• FRW/Modules/MultiRestore/ViewModel/RestoreMultiAccountViewModel.swift (1 hunk)

Actionable Comments (0)

Skipped Comments (2)

• FRW/Modules/MultiRestore/ViewModel/RestoreMultiAccountViewModel.swift [69-75]

  maintainability: "Duplicated error handling logic could be consolidated."

• FRW/Modules/MultiRestore/ViewModel/RestoreMultiAccountViewModel.swift [71-71]

  possible bug: "Inconsistent HUD dismissal between similar error handlers."

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[github-actions]

✅ LGTM!

Review Summary

Commits Considered (1)

• fe86c1f: Merge branch 'dev' into fix-revoked-key-empty-account

Files Processed (0)

Actionable Comments (0)

Skipped Comments (0)