Shield Wallet: "No response" error on first transaction attempt requires retry workaround

[Nuel-osas]

Problem

When using Shield Wallet (v0.3.0-alpha.3) with @provablehq/aleo-wallet-adaptor-react, the first executeTransaction() call after connecting consistently fails with Error: No response. The second attempt succeeds immediately. This happens regardless of the DecryptPermission setting.

Error

Error: No response
    at Object.<anonymous> (chrome-extension://hhddpjpacfjaakjioinajgmhlbhfchao/content-scripts/content.js:1:16612)
    at Generator.next (<anonymous>:null:null)
    at u (chrome-extension://hhddpjpacfjaakjioinajgmhlbhfchao/content-scripts/content.js:1:15983)

Environment

• Shield Wallet: v0.3.0-alpha.3
• @provablehq/aleo-wallet-adaptor-react: latest
• @provablehq/aleo-wallet-adaptor-core: latest
• Next.js 16 / React 19
• Aleo Testnet

Reproduction

1. Connect Shield Wallet via useWallet() → connected: true
2. Call executeTransaction(tx) with any valid transaction
3. First call fails with Error: No response
4. Call executeTransaction(tx) again with the same transaction
5. Second call succeeds — wallet popup appears and transaction goes through

This is 100% reproducible. The wallet appears to need a "warm-up" connection before it responds to transaction requests.

DecryptPermission Settings Tested

We tested all available options to see if they resolve the issue:

Setting	Result
DecryptPermission.NoDecrypt	First call still fails
DecryptPermission.UponRequest	First call still fails
DecryptPermission.AutoDecrypt	First call still fails (reduces prompts but doesn't fix the error)

<AleoWalletProvider
  wallets={wallets}
  decryptPermission={DecryptPermission.AutoDecrypt}
  network={Network.TESTNET}
  autoConnect
>

Impact

This is a serious UX issue for dApps. In our case (a data marketplace), a failed first attempt during the sell flow wastes Walrus storage — the encrypted file was already uploaded before the wallet rejected the transaction.

Workaround

We built a retry wrapper that catches the "No response" error and automatically retries once after a 1-second delay:

export async function executeWithRetry(
  executeTransaction: (tx: TransactionOptions) => Promise<{ transactionId?: string } | undefined>,
  tx: TransactionOptions,
  maxRetries: number = 1
): Promise<{ transactionId?: string } | undefined> {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    try {
      const result = await executeTransaction(tx);
      return result;
    } catch (err) {
      const msg = err instanceof Error ? err.message : "";
      if (msg.includes("No response") && attempt < maxRetries) {
        await new Promise((r) => setTimeout(r, 1000));
        continue;
      }
      throw err;
    }
  }
  throw new Error("Transaction failed after retries");
}

We also reordered our transaction flow to perform wallet signing before any irreversible operations (like file uploads) so that a failed first attempt doesn't waste resources.

Expected Behavior

executeTransaction() should succeed on the first call after the wallet is connected, or the adapter should handle the warm-up internally so dApp developers don't need retry logic.

Additional Context

We checked other Aleo dApps (private-prediction-market, NullPay) — neither handles this error explicitly. The private-prediction-market project uses DecryptPermission.UponRequest but does not have a retry mechanism, suggesting their users also experience this issue silently.

Project: VeilData — Confidential Data Marketplace built for Aleo Privacy Buildathon

[Nuel-osas]

Additional finding: Shield Wallet auto-locks after ~30 seconds regardless of the timeout/lock settings configured in the extension. When the wallet locks, any executeTransaction() call from a connected dApp returns Error: No response instead of prompting the user to unlock.

This means the "No response" error isn't just a first-call warm-up issue — it can happen at any point during a multi-step flow if the user takes more than 30 seconds between wallet interactions (e.g., filling out a form before the next signing step).

The DecryptPermission config (AutoDecrypt, UponRequest, NoDecrypt) only affects behavior while the wallet is unlocked. Once the wallet locks, the extension never reaches the decrypt/sign logic — it silently fails with "No response" before any permission check happens.

Expected behavior: The wallet should either respect the configured lock timeout, or prompt the user to unlock when a dApp requests a transaction while locked — not silently fail with "No response".