Already processing eth_requestAccounts

[tre-dev]

Describe the bug

When I close the unlock wallet popup while requesting eth accounts, I'm not getting any result. And when I request eth accounts again, I'm getting the following error MetaMask - RPC Error: Already processing eth_requestAccounts. Please wait.

Steps to reproduce (REQUIRED)

 window.web3 = new Web3(window.ethereum)
 const account = await window.ethereum.request({
      method: 'eth_requestAccounts',
 })

• Have wallet locked
• Trigger request
• Close unlock popup
• Trigger request again

Expected behavior

Receive error with specific code to know that unlock wallet has been closed as well as the transaction to be discharged from the processing pipe.

Browser details (please complete the following information):

Version 1.17.75 Chromium: 87.0.4280.88 (Official Build) (x86_64)

[tmashuang]

Is the notification number on the icon not present? After unlocking, does the pending connect request not show?

[Gudahtt]

Thanks for the report! I was able to reproduce this behaviour.

We did intend to block repeated attempts to connect, so this is working as intended. But, I hadn't anticipated that this would prevent the popup from showing up if it was accidentally closed the first time :thinking:. Ideally a user would click the MetaMask button in their toolbar to unlock, but admittedly not all of our users are in the habit of clicking that button, and some have it hidden.

This definitely seems less than ideal, but I'm not sure how we should handle this.

Receive error with specific code to know that unlock wallet has been closed as well as the transaction to be discharged from the processing pipe.

The first request to connect should return a Promise to the dapp that is still pending; that was meant to be our signal to dapps that the request is still being processed. The thought was that the reason for the delay wasn't necessarily of concern to the dapp. The only thing the dapp needs to know is that it's still awaiting approval. In an ideal world, anyway. Note that repeated connect attempts will result in this error even when the extension is unlocked.

Note that dapps can check whether MetaMask is unlocked using the experimental provider method isUnlocked, but be warned that we don't provide any stability guarantees for that method.

Returning an error that explains that the extension is locked is an interesting idea. Or it might be worth trying to re-trigger the popup for repeated connect requests while unlocked, if the popup is currently closed. Would making the popup re-appear in this case solve this problem from your perspective @tre-dev ?

[tre-dev]

Thanks for answering!

Ideally a user would click the MetaMask button in their toolbar to unlock, but admittedly not all of our users are in the habit of clicking that button, and some have it hidden.

I think it's hidden by default in Brave.

Returning an error that explains that the extension is locked is an interesting idea. Or it might be worth trying to re-trigger the popup for repeated connect requests while unlocked, if the popup is currently closed. Would making the popup re-appear in this case solve this problem from your perspective @tre-dev ?

So if I understand it correctly, the goal is to prevent multiple login tries? The primary point I have is:

I'm using await within a try/catch and I need to know when the login try has failed due to the user closing the popup page, for things like toggling a loading prop, which disables the button. An error would be perfect, so the whole login process is just "reset".

So removing the eth_requestAccounts method from the processing pipe and throwing an error, when the unlock popup was cancelled would be my preferred option. This would also not allow the user to start multiple parallel login tries. Or am I missing something?

[Gudahtt]

So the only problem with that is that user being prompted to unlock the extension is a side-effect of eth_requestAccounts, and not considered in the success or failure of that method. We prompt the user to unlock when we get eth_requestAccounts and the wallet is locked, but if they close the window and unlock the extension later instead, the eth_requestAccounts request can complete successfully.

I'm not sure that it has to be this way, but that's how we currently think of it anyway.

[tre-dev]

What would be a use-case where a user might not unlock the wallet immediately but unlocks it later and then broadcasts the saved transaction?

[Gudahtt]

I'm not sure :thinking: We prompt the user to log in right away, and generally that's what we expect them to do.

That's an interesting point. Maybe we should consider any queued requests to be 'expired' and auto-reject after waiting for the user to unlock the wallet for a certain period of time.

[Gudahtt]

We're planning on introducing a confirmation timeout, after which the confirmation would be automatically rejected. This should address the edge cases where a user inadvertently leaves a confirmation open in the background for an extended period of time, resulting in this "Already processing eth_requestAccounts" error when trying to connect again.

In re-reading this issue, I realized I missed something that you said before:

So removing the eth_requestAccounts method from the processing pipe and throwing an error, when the unlock popup was cancelled would be my preferred option.

The way it's supposed to work is that closing the popup cancels the request. I see now that you were trying to explain that this doesn't work when the popup is on the unlock screen when it gets closed. That makes sense. I would think closing the popup on the unlock screen should reject all pending confirmations. I'll double check with the rest of the team first, but I think this is a bug, as we didn't consider the unlock screen when implementing the reject-on-close functionality.

[Gudahtt]

I've followed up with the rest of the team, and we have agreed that all pending confirmations should be closed when the notification window is closed, even if it's closed when on the lock screen. An issue has been created for this here: #10302

[MWaser]

Is there any word on when this will be implemented?

Your own documentation at https://docs.metamask.io/guide/ethereum-provider.html#using-the-provider (see below) gave us an expectation of a 4001 error when the user closes the window.

This is turning into a huge show-stopper for us. We are trying to migrate from web3 and this has us blocked. Is there something we can do in the interim (other than having a bunch of novice users load the obsolete-metamask fix)?

function connect() { ethereum .request({ method: 'eth_requestAccounts' }) .then(handleAccountsChanged) .catch((err) => { if (err.code === 4001) { // EIP-1193 userRejectedRequest error // If this happens, the user rejected the connection request. console.log('Please connect to MetaMask.'); } else { console.error(err); } }); }

[rsodre]

Any news on this? This is extremelly annoying.

Metamask always opens up when a user get into my dapp, even before I call eth_requestAccounts. I can't find out why. Then if the login window is closed (of couse, why connect to a dapp before even knowing what it's about), if the user finally decides to connect, my connect button will not work, because the connection is pending.

Just resume the last opened connection request! Or give us a way to just open the MetaMask window.

[ghost]

Any news on this? I still can reproduce this bug

[Pushpit07]

Facing the same issue

[tuzz]

If you don't mind reloading the current page to re-initiate the request, here's a workaround I found:

const connectOrReloadAndConnect = async () => {
  try {
    await ethereum.request({ method: "eth_requestAccounts" });
  } catch (error) {
    const message = error.message || "";
    if (!message.match(/already processing/i)) { throw error; }

    const href = window.location.href;
    if (href.match(/connectOnLoad/)) { window.location.reload(); return; }

    const delimiter = href.match(/\?/) ? "&" : "?";
    window.location.href += delimiter + "connectOnLoad=true";
  }
};

Then add some initialization code to your page that checks if connectOnLoad is set:

const params = new URLSearchParams(window.location.search);
const connectOnLoad = params.get("connectOnLoad") === "true";

if (connectOnLoad) { ethereum.request({ method: "eth_requestAccounts" }); }

If you want to remove the query parameter after page load, you can use the History API:

const href = window.location.href.replaceAll(/[?&]connectOnLoad=true/g, "");
history.replaceState(null, "", href);

[danim72]

Same issue here, I thought I was running crazy. Any news? Thanks @tuzz for the workaround I will test it now.

[danielb2]

same here. it's very frustrating and I don't know how to solve it. Is there at least a temp fix?

[Gudahtt]

We are actively working on a solution. Sorry for the inconvenience - I realize how annoying this must be to deal with.

In the meantime, if you are a developer, I'd recommend that you allow your users to connect to your site using a "Connect" button. Do not attempt to initiate a connection when the page loads. Asking a user to connect immediately is irritating for users, and it makes this problem more likely to present itself. You can also update your button to be disabled and/or ignore additional clicks while waiting for a response, so that you don't see this error if the user accidentally clicks multiple times.

If you do see this error anyway, you can advise the user to open MetaMask by clicking the MetaMask button in their browser toolbar, and to ensure they unlock the wallet and accept any pending connect confirmations for your site.

If you are a user seeing this error, click the MetaMask button in your toolbar and unlock the wallet if necessary to see the pending connect request, which you can either confirm or reject. Either choice will make this error go away.

[rsodre]

In the meantime, if you are a developer, I'd recommend that you allow your users to connect to your site using a "Connect" button. Do not attempt to initiate a connection when the page loads. Asking a user to connect immediately is irritating for users, and it makes this problem more likely to present itself.

@Gudahtt, I would love to follow this recommendation, but Drizzle does that by default, which is super annoying, and now that it has been discontinued, I won't ve able to follow until I can replace it with something else. I don't want to go off-topic here, but since MetaMask and Truffle/Drizzle are under the same group, I just want to express my frustration to be left behind without any replacement and a time bomb on my hands, since I don't know how long MetaMask will still be compatible with my front-end.

[Gudahtt]

I get that you're frustrated, but this team has nothing to do with Drizzle. I am unfamiliar with that product, and I don't know why it would include this connect-on-page-load behavior that we discourage, and I don't know why it was discontinued. Please take up any concerns you have with that tool with them.

[Gudahtt]

This has been addressed in #12643

[AoDev]

@Gudahtt We are facing this issue and don't see any difference after the fix. (Metamask 10.8.1)

If the user closes or misses the connection popup (so it gets dismissed automatically), then Metamask shows this blue notification. (at least on Brave)

But, users may not be aware of the current situation they are in. So, our connect button stops working. We can display a message, but, I thought the PR fixed the need for that?

[Gudahtt]

Thanks @AoDev ! I'm sorry to hear that. There was a problem with how this was done that later had to be corrected, see here for details: https://github.com/MetaMask/metamask-extension/pull/13194

Essentially this was only partially fixed, but there remains a race condition that can result in a situation like you just described. This will be fixed in v10.9.0, the upcoming release, which I expect to be published next week sometime (though extension store review times can be unpredictable so it might take longer).

If you see this problem again in v10.9.0 please let us know, and I'll re-open this ticket for investigation.

[rasoul369]

Hello . I have to tell you how to install and run Im Volt in GateHub and Kevin Base, and if it is highly suspicious, then why not download it? Thank you very much

در تاریخ سه‌شنبه ۱۸ ژانویهٔ ۲۰۲۲،‏ ۲۳:۲۷ Mark Stacey < @.***> نوشت:

Thanks @AoDev https://github.com/AoDev ! I'm sorry to hear that. There was a problem with how this was done that later had to be corrected, see here for details: #13194 https://github.com/MetaMask/metamask-extension/pull/13194

Essentially this was only partially fixed, but there remains a race condition that can result in a situation like you just described. This will be fixed in v10.9.0, the upcoming release, which I expect to be published next week sometime (though extension store review times can be unpredictable so it might take longer).

If you see this problem again in v10.9.0 please let us know, and I'll re-open this ticket for investigation.

— Reply to this email directly, view it on GitHub https://github.com/MetaMask/metamask-extension/issues/10085#issuecomment-1015784917, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXCO43O6S45FX3BBIS72R4LUWXA2TANCNFSM4U5TMJIQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[cryptophonic]

seeing this error almost every time on v10.9.2 currently

[elfecho]

seeing this error almost every time on v10.9.2 currently

@mark-microtick How did you solve this problem please?

[SagnikH]

seeing this error almost every time on v10.9.2 currently

Yes, whenever I click a button to request eth_requestAccounts, while Metamask is locked, a blue number appears on the extension icon. Earlier a pop used to come up asking the users to unlock Metmask, this doesn't seem to be the case now. And that's why getting that already processing error repeatedly.

[cryptophonic]

seeing this error almost every time on v10.9.2 currently

@mark-microtick How did you solve this problem please?

I haven't yet. Right now the MetaMask never pops up - I'm wondering if it's somehow because of the self-signed certificate I'm testing with. Using Chrome / latest update and the example code from the MetaMask docs

[Gudahtt]

Thanks for the reports everyone! Re-opening this now for investigation.

[othernamesweretaken]

Yes, whenever I click a button to request eth_requestAccounts, while Metamask is locked, a blue number appears on the extension icon. Earlier a pop used to come up asking the users to unlock Metmask, this doesn't seem to be the case now. And that's why getting that already processing error repeatedly.

+1

I have also noticed that this is happening only on first time when the browser is opened. When I unlocked my metamask-> connected to a site-> disconnected to a site -> locked it again, it popped up fine.

[meg2208]

Having this issue now.

[Mouradif]

This error fires whenever you call the method eth_requestAccounts while Metamask is locked.

At the very least, the error message should be clearer

[davidrazmadze]

❌ Error reproduced:

  async function requestAccount() {
    if (window.ethereum) {
      try {
        const accounts = await window.ethereum.request({
          method: "eth_requestAccounts",
        });
        setWalletAddress(accounts[0]);
      } catch (error) {
        if (error.code === 4001) {
          alert("Error connecting");
        } else {
          alert(error.message);
        }
      }
    }
  }

[Mouradif]

@davidrazmadze

Unlock Metamask, reload the page and see if still get the error.

I actually wasn't even able to reproduce after locking Metamask, for me it only happens when Metamask is still locked from first launching the browser

[Br3ikros]

@davidrazmadze

Unlock Metamask, reload the page and see if still get the error.

I actually wasn't even able to reproduce after locking Metamask, for me it only happens when Metamask is still locked from first launching the browser

yeah but are we really expecting every user to manually unlock metamask in order for our websites to work? What do you even mean by unlocking? Is there a way to programmatically make it so metamask doesn't bug out when a user reopens one of their sessions and tries to login to the wallet?

[Br3ikros]

We are actively working on a solution. Sorry for the inconvenience - I realize how annoying this must be to deal with.

In the meantime, if you are a developer, I'd recommend that you allow your users to connect to your site using a "Connect" button. Do not attempt to initiate a connection when the page loads. Asking a user to connect immediately is irritating for users, and it makes this problem more likely to present itself. You can also update your button to be disabled and/or ignore additional clicks while waiting for a response, so that you don't see this error if the user accidentally clicks multiple times.

If you do see this error anyway, you can advise the user to open MetaMask by clicking the MetaMask button in their browser toolbar, and to ensure they unlock the wallet and accept any pending connect confirmations for your site.

If you are a user seeing this error, click the MetaMask button in your toolbar and unlock the wallet if necessary to see the pending connect request, which you can either confirm or reject. Either choice will make this error go away.

any news? The problem is still there

[chiefGui]

I noticed that this:

await provider.send('eth_requestAccounts', [])

triggers this:

provider.on('block', (eventBlockNumber) => {
  console.log(`here`, eventBlockNumber) // prints "here 418247"
})

And I even tried this:

provider.on('block', (eventBlockNumber) => {
  console.log(`here`, provider.resetBlock)

  provider.resetEventsBlock(eventBlockNumber)
})

But no success so far; it was just me digging the ethersjs API. Perhaps it may lead to a clue on how to address the issue? All that we need is to "release" the MetaMask/wallet request that is pending.

All the above said, can confirm this is still an issue & our company observed that this occurs quite often so it may be something really worth looking into.

---

We only saw this occurring with locked MetaMask wallets, which is an ordinary scenario - specially when it comes to new users and people who interact with something web3-related and still don't have a MetaMask account.

[marklee1972]

My observations: If you checkout the "Account options" of MetaMask (the icon is "vertical 3 dots")

Select the option:"Connected sites":

You will find the list of this account had approve connect to sites. Every developer's site : localhost:3000 It should be on this list. ^_^

Disconnect it and lock this account then close the metamask. Click your button to trigger below code:

ethereum.request({ method: 'eth_requestAccounts' })

Metamask will popup again !!

I think the function of connected sites list is similar cookie. Registered users have approved the dapp site and do not need to log in again. However, I would be concerned if someone visited my dapp and agreed to connect to my website. Next time he comes here in a locked state, I can't tell him to unlock it first. Maybe the metamask developers have their considerations and think it's not necessary. Or it's a matter of UI design thinking.

[amsheehan]

Still an issue when trying to connect via a button while MetaMask is locked or awaiting a password.

[AlexandreBazeaud]

Hello, It looks like calling

ethereum.request({
      method: 'wallet_requestPermissions',
      params: [{ eth_accounts: {} }],
    })

works well, it opens the popup and when you close it, handle the rejection just how we want eth_requestAccounts to work.

[adavies1]

@AlexandreBazeaud That's a good find, but (at least for me) it makes metamask request permission for the wallet to be used every time the user connects their wallet (instead of just the first time) :(

[AlexandreBazeaud]

@adavies1 unfortunately it does, but it will atleast probably help contributor to find where is the problem faster.

[7-of-9]

Absolute disgrace that this issue is still open.

[Mouradif]

Absolute disgrace that this issue is still open.

Make a PR then

[animatedcreativity]

Is MetaMask going to solve this ever?

[hazard3535]

Hello, It looks like calling

ethereum.request({
      method: 'wallet_requestPermissions',
      params: [{ eth_accounts: {} }],
    })

works well, it opens the popup and when you close it, handle the rejection just how we want eth_requestAccounts to work.

your solution helped me, I process the error and try to open the settings window, it works stably

my code:

          .request({ method: "eth_requestAccounts" })
          .then(this.handleNewAccounts)
          .catch((e) => {
            window.ethereum.request({
              method: "wallet_requestPermissions",
              params: [{ eth_accounts: {} }],
            });
          })

[Twelvelines]

Was encountering this problem lately while making the discussed request in an react frontend dapp. Weird enough, though, that in another dapp of mine (which is notably not react-based), the request call had no problem throwing a code-4001 error when the popup was closed. They practically has the same button-clicking logic of initiating and handling the request. Can provide more details on these two cases if you guys need them.

My current workaround is to make the wallet_requestPermissions request instead

// originally this
await window.ethereum.request({
    method: 'eth_requestAccounts',
}).then((addrs: any) => {
    walletAddr = addrs[0];
}).catch((err) => {
    console.error(err);
});

// now this
await window.ethereum.request({
    method: 'wallet_requestPermissions',
    params: [{ eth_accounts: {} }],
}).then((permissions: any) => {
    walletAddr = permissions[0].caveats[0].value[0];
}).catch((err) => {
    console.error(err);
});

It does the magic to get the wallet address for me, at least so far

[fzn0x]

Just want to help, sometimes it caused by locked metamask extension, try to validate your client metamask is it unlocked or not and validate your client permission.

This is my workaround:

try {
  if (window.ethereum) {
    const provider = new ethers.providers.Web3Provider(window.ethereum);
    await provider.send("eth_requestAccounts", []);
    const providerAccounts = await provider.listAccounts();
    const signer = provider.getSigner();

    const walletAddress = providerAccounts[0];
  } else {
    console.error(
      "Failed connecting to wallet, no ethereum found in your browser, please use the latest version of firefox browser or chromium browsers."
    );
  }
} catch (error) {
  yourAlertComponentDontApplyItRaw("Upgrade Plans Failed: " + error.message);

  if (
    error.message ===
    "Already processing eth_requestAccounts. Please wait."
  ) {
    yourAlertComponentDontApplyItRaw("Please sign in to your MetaMask.");
    window.ethereum.request({
      method: "wallet_requestPermissions",
      params: [{ eth_accounts: {} }],
    });
  }
}

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 45 days if there is no further activity. The MetaMask team intends on reviewing this issue before close, and removing the stale label if it is still a bug. We welcome new comments on this issue. We do not intend on closing issues if they report bugs that are still reproducible. Thank you for your contributions.

[Valkryst]

I believe I ran into this issue, or one similar to it, today.

Configuration

• Windows 11 - x64 Professional Edition
• Edge - Version 116.0.1938.62 (Official build) (64-bit)
• MetaMask Extension - 10.34.0

Steps

1. Initiate login on a website.
2. See the login popup appear, specifically the one requesting my password.
3. Close the login popup without entering my password.
4. All attempts to initiate login are now being met with MetaMask - RPC Error: Already processing eth_requestAccounts. Please wait. in the console and nothing happens on the website.

Failed Resolution Attempts

• Restarting Edge.
• Both CTRL+R and CTRL+F5 refreshes.
• Clearing all cookies.

Successful Resoltion

After a while, I opened the extension manually and noticed the login popup was being displayed again. I logged into MetaMask and then I was able to successfuly initiate login on the website, sign my login, and then log into the website.

Seems like this issue could've been resolved if the extension showed me the login popup again initially.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 45 days if there is no further activity. The MetaMask team intends on reviewing this issue before close, and removing the stale label if it is still a bug. We welcome new comments on this issue. We do not intend on closing issues if they report bugs that are still reproducible. Thank you for your contributions.

[TetianaMolchanova]

const isRequestActive: Ref<UnwrapRef> = ref(false); if (isRequestActive.value) { console.warn("NEW A request is already active. Please wait."); return; }

console.log('if AFTER', );

try {
    // Example: Requesting account access
    const accounts = await (window.ethereum as any)?.request({ method: 'eth_requestAccounts' }).then((account) => console.log('account', account)).catch((error: unknown) => console.error('error', error)).finally(() => console.log('finally', ));
    // Proceed with additional actions like showing balance, switching chains, etc.
    console.log('NEW accounts', accounts);
    isRequestActive.value = true;
} catch (error) {
    console.error("NEW Error interacting with MetaMask:", error);
    // Handle error appropriately
    isRequestActive.value = false;
} finally {
    console.log('NEW finally isRequestActive.value', isRequestActive.value);
    isRequestActive.value = false;
}
console.log('metaMaskCall end', );

For catching error here the magic is done in this line of code above: 

const accounts = await (window.ethereum as any)?.request({ method: 'eth_requestAccounts' }).then((account) => console.log('account', account)).catch((error: unknown) => console.error('error', error)).finally(() => console.log('finally', ));

We caught this error in .catch method of request.

this code is for Vue 3 with typescript