32603 код ошибки метамаск

I am getting this error when i trying to use metamask on my local for a simple transaction from one account(say A) to another (say B).

code: -32603
data: {originalError: {…}}
message: «Internal JSON-RPC error.»
stack: «Error: WalletMiddleware — Invalid «from» address.↵ at h (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background.js:1:1226252)↵ at async chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background.js:1:1224243″
proto: Object

Solutions I tried on my own(which didn’t work ofc):
1. Downgrading my web3.js to beta 33,35 and 37 release. Currently, I am using 1.2.0 version.
2. Changing my metamask to mainnet and then back to local test net, which I am running on port:9545

Below is my smart contract:

contract ApprovalContract {
    address payable public sender;
    address payable public receiver;
    address public constant approver = <some account address>;

    function deposit (address payable _receiver) external payable {
        require(msg.value > 0);
        sender = msg.sender;
        receiver = _receiver;
    }

}

And below is my custom js (using web3.js)

var web3 = new Web3(Web3.givenProvider || "ws://localhost:9545");

var contractAddress = <contractAddress>;

var ApprovalContract = new web3.eth.Contract(ABI, contractAddress); 

$('#contract-form').submit(function() {
  event.preventDefault();
  var fromAddress = $('#fromAddress').val();
  var toAddress = $('#toAddress').val();
  var amount = $('#amount').val();

  ApprovalContract.methods.deposit(toAddress).send({"from": fromAddress, "value": web3.utils.toWei(amount,'ether')},
    function(error, result) {
      if (error) {
        console.log('error: ' + error);
          $('#deposit-result').html('Error: ' + error);
      } else {
        $('#deposit-result').html('Success TX: <b>' + result + '</b>');
      }
    });
});

The flow is going into the last function and displaying the error as below:

error: Error: Internal JSON-RPC error.
{
  "originalError": {}
}

Expectation: Since my account A, is the account[0] of Metamask where is logging in to, I am expecting the Metamask pop up to show to confirm the transaction but instead I am getting this «Internal JSON RPC errror.»

Any ideas ???

Thanks in advance!!!

I am getting this error when i trying to use metamask on my local for a simple transaction from one account(say A) to another (say B).

code: -32603
data: {originalError: {…}}
message: «Internal JSON-RPC error.»
stack: «Error: WalletMiddleware — Invalid «from» address.↵ at h (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background.js:1:1226252)↵ at async chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background.js:1:1224243″
proto: Object

Solutions I tried on my own(which didn’t work ofc):
1. Downgrading my web3.js to beta 33,35 and 37 release. Currently, I am using 1.2.0 version.
2. Changing my metamask to mainnet and then back to local test net, which I am running on port:9545

Below is my smart contract:

contract ApprovalContract {
    address payable public sender;
    address payable public receiver;
    address public constant approver = <some account address>;

    function deposit (address payable _receiver) external payable {
        require(msg.value > 0);
        sender = msg.sender;
        receiver = _receiver;
    }

}

And below is my custom js (using web3.js)

var web3 = new Web3(Web3.givenProvider || "ws://localhost:9545");

var contractAddress = <contractAddress>;

var ApprovalContract = new web3.eth.Contract(ABI, contractAddress); 

$('#contract-form').submit(function() {
  event.preventDefault();
  var fromAddress = $('#fromAddress').val();
  var toAddress = $('#toAddress').val();
  var amount = $('#amount').val();

  ApprovalContract.methods.deposit(toAddress).send({"from": fromAddress, "value": web3.utils.toWei(amount,'ether')},
    function(error, result) {
      if (error) {
        console.log('error: ' + error);
          $('#deposit-result').html('Error: ' + error);
      } else {
        $('#deposit-result').html('Success TX: <b>' + result + '</b>');
      }
    });
});

The flow is going into the last function and displaying the error as below:

error: Error: Internal JSON-RPC error.
{
  "originalError": {}
}

Expectation: Since my account A, is the account[0] of Metamask where is logging in to, I am expecting the Metamask pop up to show to confirm the transaction but instead I am getting this «Internal JSON RPC errror.»

Any ideas ???

Thanks in advance!!!

Internal JSON-RPC error -32603 for big contract on mainnet #3117

Just posting this here cause this error pops up while deploying big contract on mainnet from remix.
Not sure it is completely related to metamask though.

Invalid JSON RPC response: <«id»:858,»jsonrpc»:»2.0″,»error»:<«code»:-32603>>
comment from user :
«I managed to deploy small contracts on mainnet and it’s fine, then i tried a longer contract on mainnet it fails while, the exact same code is fine on Ropsten and Rinkeby»

The text was updated successfully, but these errors were encountered:

What version of MetaMask are you on?

3.13.7
seems to work when a mainnet Custom RPC server is setup

This might be fixed later today, let us know tomorrow if you could if this is still happening. Has to do with a new REST API we’re using with Infura.

3.13.8
I’m getting the same kind of error when deploying a contract.
I suspect that the issue comes from infura too.
It happens 3 out of 4 times.

Mine is a HTTP 500 error.

To isolate this, we could really use strong reproduction steps. That would be either the contract code that you can’t deploy, or the exact request that is throwing this error.

To copy the request:

1. Open the background inspector as described here under «Background Logs».
2. Click the Network tab.
3. Reproduce the issue.
4. Look for a red item in the network list.
5. Right-click that item and click Copy as cURL
6. Paste that result either here or to us in an email to support@metamask.io

here is a code sample that is reported to replicate the issue:

Alright, Infura believes they’ve found the root of this problem, and say it should be fixed now!

If anyone can confirm this isn’t fixed, I will re-open.

Источник

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

yarn add @metamask/rpc-errors

npm install @metamask/rpc-errors

• Ethereum JSON RPC
  • Per EIP-1474
    • This includes all JSON RPC 2.0 errors
• Ethereum Provider errors
  • Per EIP-1193
    • Does not yet support CloseEvent errors or status codes.

Parsing Unknown Errors

• Install Node.js version 16
  • If you are using nvm (recommended) running nvm use will automatically choose the right node version for you.
• Install Yarn v3
• Run yarn install to install dependencies and run any required post-install scripts

Testing and Linting

Run yarn test to run the tests once. To run tests on file changes, run yarn test:watch .

Run yarn lint to run the linter, or run yarn lint:fix to run the linter and fix any automatically fixable issues.

The project follows the same release process as the other libraries in the MetaMask organization. The GitHub Actions action-create-release-pr and action-publish-release are used to automate the release process; see those repositories for more information about how they work.

Источник

May 6, 2022 6 min read 1737

MetaMask gives us the ability to access decentralized applications (dApps) while offering a form of authentication using the MetaMask wallet. It provides a one-click secure login flow that allows us to access the blockchain resources using ethers on the front end. MetaMask abstracts delicate processes like signing transactions while interacting with the blockchain, and provides your MetaMask’s public address to the application.

Thus, as developers, when building these dApps, there are bound to be errors, and these errors should be handled appropriately so both the developers and users can know what is wrong. Because the MetaMask documentation does not have a comprehensive and clear guide to the many types of errors that might come up while working with MetaMask, I have compiled a list here of the most common errors and what they mean.

You can jump to the error codes outlined in this article with the following links:

When trying to connect to the wallet, if a user clicks “Cancel” at any point on this interface and terminates the process, it returns a 4001 error.

Here’s the JSON structure of the error:

This error occurs when the dApp wants to take action concerning an account that is not authorized.

For instance, to do certain actions like signing a message, you need to first get account permission from MetaMask, using the eth_requestAccounts method:

Similarly, to switch the chain of your wallet, you need to use the wallet_switchEthereumChain method, which in turn asks for permission through MetaMask extension:

If the permission is denied, the wallet returns this error:

MetaMask enables two methods: restricted and unrestricted. These methods allow the dApp to take actions like connecting to the wallet, signing transactions, and adding or switching networks.

This error is returned for the methods that aren’t supported on MetaMask:

This error is returned when the user’s MetaMask wallet is not connected to any chain:

It has to do with the disconnect event. This event is triggered when the wallet is disconnected and it becomes unable to submit requests to a chain. Besides disconnection, this can also happen due to network connectivity issues.

Once we emit disconnect , the provider will not accept any new requests until the connection to the chain has been reestablished, which requires reloading the page. You can also use the ethereum.isConnected() method to determine if the provider is disconnected.

Here’s the error’s JSON response:

This error means the user is not connected to the appropriate chain for that transaction. For example, if a transaction requires the user to be on the Polygon chain, and they’re on Harmony or Ethereum blockchain.

One thing to note is that the MetaMask provider allows us to listen to the chainChanged event that listens and acts if the currently connected chain changes:

We submit our RPC requests to the currently connected chain, which makes it important to keep track of the current chain ID by listening for changes. Every chain has its unique chainID, which you can find on Chainlist.

It returns the error if it becomes unable to submit RPC requests to that specific chain:

32700

This error is returned if the user sends an incomplete request object to the contract. It can occur if the object sent to the contract does not contain all the data that it requires.

Here’s the JSON response:

32600

Here, the object is valid, but the structure or properties aren’t correct. It’s somewhat similar to 32700, but in this case, it’s the internal structure that’s not correct.

Here’s the JSON response:

32601

This error is returned if the method specified does not exist at all:

32602

We get this error if the arguments passed into an RPC method is incorrect. For instance, when defining the transactionParameters , the from property references accounts[0] .

Ordinarily, accounts[0] is supposed to be the user’s wallet address, but in this case, we assign it to an empty array:

The Mint function will return this particular error because the parameter is clearly invalid:

32603

This is a blanket error caused by several things. It might be because you’re trying to add a new chain to your wallet (manually or through the dApp) but added the wrong chain data. Or, you’re trying to complete a transaction, but you don’t have enough tokens to pay the gas fee. For instance, if you’re transacting on the Ethereum mainnet, you have to pay gas fees in ETH regardless of whether you’re transacting using other tokens.

Finally, it could be as trivial as not having the latest version of MetaMask.

Here’s the error JSON response:

32000

One scenario that can trigger this error is when the contract address used in production is the contract you deployed to the testnet. This is a simple error that we can correct.

Similar to Web2 where we have a dev environment and a production environment, when building dApps, we use testnet to deploy our contract, so we can test it while building without using real ETH on mainnet. As such, the same contract deployed on testnet and mainnet will have different addresses. If you use the wrong address for the chain you’re on, this error is returned.

Over 200k developers use LogRocket to create better digital experiences

In general, when dealing with smart contracts, you need params like the contract address, the ABI file, and your signer:

If any of these params are wrong, you’ll most likely get his error, also referred to as a “user input error”:

32001

In this case, the resource we’re requesting does not exist on the blockchain. It’s possibly a typo from the client side.

Imagine you’re trying to get info about a non-existent block number on the ETH chain:

You would get this JSON response:

32002

This error means the requested resource does exist, but it’s currently unavailable at the time of the request. This can occur when we are trying to access a resource that’s currently in use. It can happen on the MetaMask extension when you’re trying to use a particular resource/method, like switching chains when the MetaMask is currently in the process of doing the same.

When building your dApp, you should learn to disable your button once that method has been successfully initiated, so user is not clicking in quick succession.

Here’s this error’s JSON response:

32003

This error could be a result of many things. It could be because the sender’s address doesn’t exist, insufficient funds, the account is locked, or we can’t sign the transaction. To fix this, make sure everything in your transaction is correct.

The transaction can be rejected if the conditions needed to complete the transaction aren’t satisfied:

32004

The method is not supported at all. Possibly, it doesn’t exist or there’s just a typographical error:

32005

This error means the RPC provider has a rate limit that has been exceeded. This issue can occur if the RPC provider endpoint has a rate limit for the number of requests:

Also, there’s a fairly common error with the error message “intrinsic gas too low.” It’s simply because the gas limit that’s assigned when initiating the transaction is less than what is required.

This occurs most often in cases where there’s a complex transaction, which can make the gas fee unpredictable:

Conclusion

Congratulations if you’ve made it to the end! We covered a bunch of possible errors and how to deal with them. Now, when building your next dApp, you can easily interpret these errors and fix them without being confused about what caused them in the first place. This can help improve your developer experience dealing with these Web3 technologies.

You can check out more about MetaMask errors from the official resource.

Join organizations like Bitso and Coinsquare who use LogRocket to proactively monitor their Web3 apps

LogRocket is like a DVR for web and mobile apps, recording everything that happens in your web app or site. Instead of guessing why problems happen, you can aggregate and report on key frontend performance metrics, replay user sessions along with application state, log network requests, and automatically surface all errors.

Modernize how you debug web and mobile apps — Start monitoring for free.

Источник

Describe the bug
Sometimes, MetaMask reports a transaction as having failed, when it is still in the tx pool and might still execute.

Steps to reproduce (REQUIRED)

1. Have an account with some ETH. Private-net ETH like you’d have on a Ganache instance running locally likely suffices; in my case I had geth running locally. Use a new account created just for this test, which has no prior transactions. In this test, the account was prefunded with 10 ETH.
2. Have another account to receive some ETH.
3. In Metamask Settings-> Advanced, turn on «Customize transaction nonce.»
4. Trigger a 3 ETH transaction from sender to recipient, manually setting the nonce to 2. This will help prevent the transaction from going through, simulating a variety of other hard-to-manually-reproduce conditions. In my test, I used a 50 Gwei gas price.

This transaction will remain Pending:

In Geth logs, I could see the transaction submitted, followed by lines about every 30 seconds saying:

WARN . Served eth_sendRawTransaction . err=»already known»

Click Cancel:

Then click «Yes, let’s try.»

In the transaction history, the amount changes to 0 and the Cancel button disappears:

Geth logs show the submitted transaction and about every 20 seconds this warning:

WARN . Served eth_sendRawTransaction . err=»replacement transaction underpriced»

Suppose I want to speed up that 0 ETH / cancellation transaction, or recognize this «underpriced» error as requiring a higher gas price. I might click the only visibly remaining option, Speed Up:

Click Fast, and save.

A failure popup is observed very briefly, and upon inspecting the MetaMask popup console, the error is seen in more detail, with message:

«[ethjs-query] while formatting outputs from RPC ‘<«value»:<«code»:-32603,»message»:»Internal JSON-RPC error.»,»data»:<«code»:-32000,»message»:»replacement transaction underpriced»>,»stack»:»Error: Internal JSON-RPC error.n at s (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background.js:60:361390)n at Object.internal (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background.js:60:361793)n at l (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background.js:60:35483)n at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background.js:60:34639″>>’»

Notice that Metamask clearly reports the transaction as having failed:

though Geth continues to put out the «replacement transaction underpriced» note every 20 seconds or so, suggesting the tx is still in the pool.

Send another small transaction, accepting default nonce:

This should go through and be confirmed.

Note that this transaction appears below the failed transactions in the transaction history, because it has a lower nonce.

Send another small transaction, which should go through too:

Popups show transaction 1 confirmed, then transaction 2 confirmed, and that transaction changes from Failed to Cancelled, with the cancellation fee charged:

Initiate another transaction like the first, with nonce 4.

As before, this transaction remains pending, with the «already known» error in geth logs

Click Cancel, and accept gas fee:

The transaction amount is now 0 but still pending, with the periodic «already known» errors replaced by «replacement transaction underpriced» errors.

Click Speed Up, thinking this might speed up cancellation (as any visible Cancel option has disappeared), and select Average speed, then Save:

The transaction remains pending, but Geth «replacement transaction underpriced» errors continue:

Click Speed Up, go to Advanced, and enter a high gas price like 43000:

The transaction remains pending and Geth keeps saying «replacement transaction underpriced.»
Click Speed Up again, and go to Advanced, saving the default value filled in of 47300:

The transaction remains pending and Geth keeps saying «replacement transaction underpriced» in its logs.

Note that the Speed Up button is gone.

However, clicking on the transaction, there are details:

Notably, there are two different links here: «Speed up this cancellation» and «Speed up this transaction.» At this point, the user might recognize that «Speed up this cancellation» is what they have been trying to do, and notice the subtle change that AFTER they submitted a Cancel transaction and the Cancel button disappeared, subsequent speed-up attempts resubmitted the original 3 ETH transaction.

So here, the user clicks «Speed up this cancellation.» A higher cancellation fee is posted:

The user clicks «Yes, let’s try.»

A failure message pops up very briefly, but clicking on it causes the popup to disappear even faster, rather than providing any details. Inspecting the MetaMask logs (which the average user should not be expected to know how to do) reveals this error:

«[ethjs-query] while formatting outputs from RPC ‘<«value»:<«code»:-32603,»message»:»Internal JSON-RPC error.»,»data»:<«code»:-32000,»message»:»tx fee (1.09 ether) exceeds the configured cap (1.00 ether)»>,»stack»:»Error: Internal JSON-RPC error.n at s (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background.js:60:361390)n at Object.internal (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background.js:60:361793)n at l (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background.js:60:35483)n at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background.js:60:34639″>>’»

Note: Both this and the error above use codes 32603 and 32000. That seems to violate the spirit of using different codes for different errors: you have two different codes for the same error and/or two different errors using the same code.

In earlier testing trying to develop these steps to reproduce, simply clicking «Speed up this cancellation» several times without having ever sped up the original transaction results in an AssertionError «The field gasPrice must not have more 32 bytes» error, usually within 10-12 speedups of the cancellation. In any case, the user is not informed about the 32-byte cap, or why that failed.

At this point, MetaMask shows the transaction as having finally failed. one might think this has a similar outcome to cancellation, perhaps without the cancellation fee, and a final notice that the transaction will NOT go through. Further, this is a 0-ETH transaction now because it was cancelled, so in the worst case it’d be charging the cancellation fee:

Then, send a small transaction, accepting the default nonce:

This shows as pending for a bit:

Then, notification popups show that transaction 4 is confirmed, followed shortly by transaction 3. While confirmation of transaction 3 was expected, confirmation of transaction 4 was not; the interface had showed it in a final state as Failed. Further, the amount the transaction was confirmed for was 3 ETH, despite that the transaction had been cancelled!

The user’s balance is adjusted downward to match. The user, who might have re-initiated a transaction that failed, may have doubled the transaction intended, which could lead to quite negative results, depending on what the transaction does.

Expected behavior

1. MetaMask’s UI does not allow submission of a cancellation transaction with a too-high gas price (>32 bytes), communicating the upper limit to the user. If there is a chain-specific limit for the tx fee (default value of 1 ETH on this private PoA chain) that MetaMask can find out about, that limit is similarly presented and respected.
2. Errors are visible to the user in some way.
3. When errors are passed to a dapp, each unique error has a unique code.
4. If an attempt to replace a previous transaction fails, but the transaction the user attempted to replace is still in the pool, the transaction is not marked as Failed. There may be some way to communicate to the user that the attempt to speed up the transaction failed.
5. After the user has clicked to Cancel a transaction and submitted that cancellation, the Cancel button does not disappear, but becomes «Speed up cancellation.» The «Speed up» button either disappears or becomes «Resubmit & speed up original transaction.»
6. The UI for speeding up a tx and speeding up a tx cancellation are much more similar than they currently are.
7. When submitting a transaction with a higher gas price, Geth logs should not show «replacement transaction underpriced» (not sure if this is an issue in Metamask or elsewhere).
8. When an alert is shown (e.g. «Nonce is higher. » from first screenshot), the popup grows a little taller so the reject/confirm buttons don’t get cut off.
9. Gas prices suggested for private networks aren’t drawn from current gas price conditions on mainnet.
10. Transactions are shown in the order they are mined, sorted first by block number and then transaction number within the block, rather than nonce. Pending transactions are shown on the most-recent end. Failed transactions may be sorted by timestamp, in the sequence where they would be if they had succeeded instead.

Some of those may need to be spun off into separate Issues with links back here.

A transaction with an incorrect nonce not succeeding is just used as a way to simulate / reliably reproduce a condition of a transaction remaining pending for a long time. I’m not listing that failure to confirm as a deviation from expected behavior here.

Browser details (please complete the following information):

• OS: Windows 10
• Hardware Wallet: Not in use here
• Browser: Chrome 86.0.4240.183 (Official Build) (64-bit)
• MetaMask Version: 8.1.3

The text was updated successfully, but these errors were encountered:

Источник

I have a dApp that leverages ERC721 contract which allows users to upload images onto IPFS and transfer them to each other.
User A can upload images fine and transfer them fine to User B. Once transferred User A can still upload new images -perfect! However, when User B then logins onto Metamask and try’s to upload sketch’s(string value of hash) I am hit with the error message below.

MetaMask - RPC Error: Error: [ethjs-query] while formatting outputs from RPC '{"value":{"code":-32603,"data":{"message":"VM Exception while processing transaction: revert","code":-32000,"data":{"0x33acf11f7fb6df195a58a8cd8e21a0f837f2710540f19122548f625ba5a5aef6":{"error":"revert","program_counter":6758,"return":"0x"},"stack":"c: VM Exception while processing transaction: revertn at Function.c.fromResults (/usr/local/lib/node_modules/ganache-cli/build/ganache-core.node.cli.js:4:194812)n at w.processBlock (/usr/local/lib/node_modules/ganache-cli/build/ganache-core.node.cli.js:42:53376)n at process._tickCallback (internal/process/next_tick.js:68:7)","name":"c"}}}}'

I have a truffle test which passes when a user uploads, transfers and then uploads again. Do I need a truffle test for a different account accessing and uploading sketch’s to expose this problem? If so how do you change the accounts address accessing the contract in truffle test environment?
I begin the truffle test.js and expose the contract as follows:

const Sketch = artifacts.require('./Sketch.sol')

require('chai')
  .use(require('chai-as-promised'))
  .should()

contract('Sketch', (accounts) => {
    let contract

    before(async () => {
        contract = await Sketch.deployed()
    })

    describe('deployment', async () => {
        it('deploys successfully', async () => {
            const address = contract.address
            assert.notEqual(address, 0x0)
            assert.notEqual(address, '')
            assert.notEqual(address, null)
            assert.notEqual(address, undefined)
        })

Any help would be great