Web3.js: await is not working with send method

[logeekal]

This is first time i am raising an issue and i have already searched and there nothing of same kind i could find. I apologise for anything that may not be correct. Please point that out and i am will be happy to make amends.

Thank you in advance for looking into this.

Description

1. send method for call contract methods doesn't seems working with await. I can see the transactions created in ganache-cli, but await never resolves the promise.

2. If i change the await syntax to generic callback or then chain, send works fine.

Expected behavior

await contract.methods.set(5).send({ from: accounts[0] }) should resolve the promise.

and then calling
const response = await contract.methods.get().call(); should get the value that is returned by get method of smart contract in the response.

Actual behavior

Program does not move beyond
await contract.methods.set(5).send({ from: accounts[0] })

No statement written after this gets actioned. It seems as if there is some exception happening but i do not see that as well in try catch.

Steps to reproduce the behavior

1. Clone this repo:
   https://github.com/hugo2soo/react

1. run ganache-cli with 8545 as the configuration.

2. Make sure metamask is not running and app connects to your local ganache chain.

3. truffle migrate

4. cd client

5. yar install

6. yarn start.

Now storage value should be displayed as 5 or anything we set in line 42 of ./react/client/src/app.js. but it is displayed as zero.

version used :
Web3.js v1.0.0-beta.37

Error Logs

No Errors.

Gists

Soli

Versions

• web3.js: v1.0.0-beta.37
• nodejs: v10.15.1
• browser: Chrome: 74.0.3729.157
• ethereum node: Not sure how to find version for this. But i am using ganache-cli version as below :
  Ganache CLI v6.4.4-beta.0 (ganache-core: 2.5.6-beta.0)
• solidity :v0.5.0

[nivida]

Thanks for opening this issue! Did you test it with the latest version of Web3 too?
(be aware to configure the transaction confirmation workflow if you use the latest version)

[pjonson2]

I am also having this issue. Here is my code.

const contract = new web3.eth.Contract(_ABI);

    await web3.eth.accounts.wallet.add({
        address:_publicKey,
        privateKey: _privateKey.toString()
    });
    const contract_Instance = await contract.deploy({
        data: _bytecode,
        arguments: _constructor_args})
        .send({
            from: _publicKey,
            gas: 1500000,
            gasPrice: '20000000000'
        });
    return contract_Instance;

Here is the console output:

UnhandledPromiseRejectionWarning: Error: No privateKey given to the TransactionSigner.

I am using web3^1.0.0-beta.55

[pjonson2]

Any help would be great!

[nivida]

@pjonson2 Is it possible to reference the whole code or a GitHub repository?

[leonprou]

await in JS is syntactic sugar for Promises..

This looks more like an integration issue between web3 and truffle, something not connected right. Maybe better to add the account and then create the contract. I think this question more suited for stackoverflow.

[logeekal]

await in JS is syntactic sugar for Promises..

This looks more like an integration issue between web3 and truffle, something not connected right. Maybe better to add the account and then create the contract. I think this question more suited for stackoverflow.

Sorry i may seem ignorant here. but if we are calling web3 api which is a official library how is truffle is playing a role there.

[leonprou]

@logeekal This was a vague guess, but turns out it got some sense.

Usually I use to run JS tests on contracts. In that scenario I don't need web3 at all, libs in truffle-suits handles the keys provision and management.

To make your example work without Metamask I needed to do this manually. When you run ganache it gives you a list of available accounts and private keys. So I took the first pair: account, privateKey and added it to web3:

        const provider = new Web3.providers.HttpProvider(
          "http://127.0.0.1:8545"
        );

        const web3 = new Web3(provider);
        web3.eth.accounts.wallet.add({
          address: account,
          privateKey: privateKey
        });

On every run ganache generates new accounts. To make it less tedious you can supply ganache-cli --accounts param. Look at the docs. Then you can even add this given account to Metamask and run the Dapp with Metamask (connected to localhost:8545).

[RichardQin918]

Have the same issue.
I am using await for my payable functions
Using truffle-hdwallet-provider as provider
However, on etherscan, it shows the transaction has went through, but the async response is never received
```
async _method(methodName, params = [], constant = true, optsExtra = {}) {
console.log('CALLING: ', methodName)
if (('value' in optsExtra || 'data' in optsExtra) && constant === true)
throw new Error('invalid operation')

let func = 'call'
let options = Object.assign(optsExtra, { from: this.from_address })
options.nonce = await this.web3.eth.getTransactionCount(this.from_address)

if (constant === false) {
  func = 'send'
  try {
    let gasPrice = await this.web3.eth.getGasPrice()
    let gasPriceFactor = parseInt(config.get('SC_GAS_PRICE_FACTOR'))
    options.gasPrice = parseInt(gasPrice) * gasPriceFactor
    const gasFactor = parseInt(config.get('SC_GAS_FACTOR'))
    let gas = await this.contract.methods[methodName](...params).estimateGas(options)
    options.gas = gas * gasFactor
  }
  catch (error) {
    console.error('Error while estimating gas', error)
  }
}

let retry = false
do {
  try {
    if (retry) {
      options.nonce++
    }
    let res = await this.contract.methods[methodName](...params)[func](options)
    console.log('this is response for contract call: ', methodName, res)
    retry = false
    return res

  }
  catch (error) {
    console.error('CONTRACT CALL ERROR! :', methodName, error)
    console.log('retrying? ', retry)
  }
} while (retry)

}

[leonprou]

This is a little embarrassing but after updating to web3-55 I've got a similar issue.
My code:

  const web3 = new Web3(providerUrl)
  const account = web3.eth.accounts.wallet.add(add0xPrefix(pk))
  new web3.eth.Contract(ABI).deploy({ data: bytecode, arguments: [name] })
    .send({ from:, gas , gasPrice })

Tried both await and then / catch, on Ropsten and on "private" Ethereum chain.
As @RichardQin918 stated the transaction is getting confirmed. I even view through Wireshark that I'm getting the receipt back.

I don't think that my problem is related to the original issue or to the pjonson2 comment. Here seems that web3 isn't resolving the promise..

[RichardQin918]

@leonprou Some new discoveries. For me the only working version would be 1.0.0-beta.37 as suggested by truffle-hdwallet-provider https://www.npmjs.com/package/truffle-hdwallet-provider

Also, I tried a weird attempt with ver.55 , which is calling await on send method and the same time using event emitter to catch receipt. As ridiculous as it seems, it printed out the confirmation receipt as I wanted, but I can not return the value or use it.

I would not suggest staying with ver.37, as it may lead you to bunch of other potential issues, but that is what I am doing right now.

Also, I traced back this issue and it has already been broughtout in ver.48 as well as ver.52 https://github.com/ethereum/web3.js/issues/2462

Think they claimed it is fixed with #2721, #2462, but not sure which release it is in
```
await this.contract.methods.create().send(options)
.on('transactionHash', (hash) => {
console.log('CREATING hash:', hash)
})
.on('confirmation', (confirmationNumber, receipt) => {
console.log('CONFIRMATION receipt:', confirmationNumber, receipt)
if (receipt.Created) {
let res = receipt.events['Created'].returnValues['feed']
console.log('this is res: ', res)
return res
}
})

[leonprou]

@RichardQin918 Ok I've found my problem, looks like you got the same one.. There's transactionConfirmationBlocks option that was introduced somewhere in between v37 and v54. It determines how many block confirmations are needed to finalize the transaction and resolve the promise with the receipt. And it's a nice feature and all, but it turns out that the default is 24.. So:

await new web3.eth.Contract(ABI).deploy({ data: bytecode })
    .send({ from:, gas , gasPrice })

Will be done after 6 mins on average (24 * 15). But you gotta be really stubborn to wait for that like to finish 6 mins, and when it does it feels like black magic. And that's why you get the confirmations..

So try to add this options to the initialisation of the contract:

// for example wait 3 blocks until the promiEvent is resolved.
new web3.eth.Contract(ABI, undefined, {transactionConfirmationBlocks: 3})

[RichardQin918]

@leonprou Thank you so much. I tried and it does work like magic :)

[leonprou]

@RichardQin918 great!

@nivida I think that the various defaults of web3 and Contract options should be added to the docs.. Also the default of 24 for transactionConfirmationBlocks is IMO too high. It was always the case in Bitcoin and Ether that 6-8 blocks are enough for finalising the transaction. For example POA bridge by default is asking for 8 confirmations (and while you develop stuff 1 confirmation is enough).

Also as sidenote.. A migration guide from ~web3v30 to the latest would be neat idea if we want more people to update.

[jamesattard]

Thanks @leonprou - I had noticed that it will resolve eventually (yes, I am stubborn) and was looking at the documentation on how to speed it up. Luckily I found the answer here before.

[nivida]

I think that the various defaults of web3 and Contract options should be added to the docs..

The default values are added here but I should probably write that explicit down.

Also the default of 24 for transactionConfirmationBlocks is IMO too high. It was always the case in Bitcoin and Ether that 6-8 blocks are enough for finalizing the transaction.

I've overtaken the default values from before. You didn't notice it because it was only waiting for these 24 blocks on the mainnet.

Also as sidenote.. A migration guide from ~web3v30 to the latest would be neat idea if we want more people to update.

Yes, this is true.

I've closed this issue because it was a configuration problem.

[leonprou]

@nivida Well it looks like many devs are still struggling with this..

[mattfysh]

Was running into this issue also, and found a couple of things:

1. The behaviour where a PromiEvent will not resolve or reject when there are receipt or error listeners attached is not immediately obvious. Perhaps expose the Observable directly, and provide a utility for those wanting to convert Observables into Promises.

2. There may be a race condition occurring when the provider supports subscriptions. I was running into an intermittent issue where sometimes the confirmation and receipt events were not firing (~50% of the time). I had configured { transactionConfirmationBlocks: 1 } and I believe that the race condition occurs when the transaction observer spins up the subscription. Sometimes it occurs _after_ the new head has already been created, meaning that the subscription is started too late, misses the newHeads event, and as such - never resolves.

[isaacdchan]

Ran into this problem. Used { transactionConfirmationBlocks: 1 }. Solved the problem.

Is this a production safe solution though? Is it the case that the less block confirmations are needed to finalize a transaction, the less secure it is?

[mattfysh]

From my understanding, this is a policy choice that's left up to the user. The less blocks you require before confirming a transaction, the more likely the transaction may be rolled back when the block it is contained within is orphaned/becomes an uncle (I don't remember the exact terminology). 1 is definitely too low, as uncle blocks are occurring all the time, last I checked a few months ago every 6th or 7th block was an uncle block (effectively not part of the mainline tx's branch). The most common I found were people waiting 6 blocks before confirming the transaction. A good indicator is to check the off-ramp providers and see how many confirmation blocks they require. Since they're dealing with actual fiat cash they're requirements are quite stringent.

If you have any other questions I'm happy to try and help, especially if they relate to building a UI on top of this concept since I once did a deep-dive investigation into this very thing I can try to answer or at least point you in the right direction. Cheers!

[aenhsaihan]

Is this all somehow related to https://github.com/ethereum/web3.js/issues/1102?

I've been getting this error message on web3.js 1.3.0 which I thought was related to the issue discussed.

Any tips?

[nikita-fuchs]

Amazing how this issue can persist for years :/ v. 1.2.7 shows exactly this behaviour: nothing happens when using await even when the transaction is through. Code:

 tx = await myContract.methods.theMethod(oneUser.address).send({
            gas: options.gas,
            gasPrice: premiumGasPrice,
            transactionConfirmationBlocks: 3
        });

[elon-goat]

I am getting the same thing, that after await call to a contract's method, nothing is actioned.
I am using web2 v1.3.1.
What I have tried?

• Tried using the blockConfirmation behaviour but without any success

• Tried with the traditional .then() call still without any success

I want to understand why this happens? As before a week or so, everything was working as expected and suddenly now it has started breaking.

[GregTheGreek]

@nikita-fuchs can you try using the latest version of web3.js? v1.3.1?

@elon-goat I just re-created it here can you confirm this does not prove it works?

[elon-goat]

@GregTheGreek Please check this, I think the issue is with MetaMask and Web3.js #10216
The MetaMask team has released MetaMask v9.0.2 which addresses this issue and is available on FireFox as of now and by the end of the week or Monday, these updates shall be made available on Chrome too.
For those of you who are wondering what am I doing wrong? earlier the await thing was working but right now it is not, what did I mess up? Take a break from all this and go and check out the issue #10216

[GregTheGreek]

I commented on that issue and spent most of yesterday with the metamAsk team.

Not sure if your issue is directly related but I can't reproduce it.