.Then() and await on .Send() never completing in VueJS + MetaMask

[devedse]

Description

I just recently upgraded to version 1.0.0-beta.51 and am now running into an issue where I can't seem to be able to wait for transactions to finish.

My webpage makes use of Metamask as a provider:

const web3 = new Web3((window as any).web3.currentProvider);

Then I load the contract:

const accs = await web3.eth.getAccounts();

const theGasPrice = web3.utils.toWei('2.1', 'gwei');

const ctr = new web3.eth.Contract(theCtr.abi as AbiItem[], store.state.contractAddress, {
    data: theCtr.bytecode,
    gas: 7500000,
    gasPrice: theGasPrice,
    from: accs[0],
});

When I then do this:

async onSubmit(evt: Event) {
      evt.preventDefault();

      try {
        const transResult = await ctr.methods.createLocation(this.form.theName).send();

        console.log('done!!!');
      } catch (ex) {
        const error = ex.toString();
        console.log(error);
      }
    },

The log message done!!! is never displayed. Even though metamask correctly pops up a message that the transaction succeeded.

In the screenshow below the application that makes use of this can be seen. Previously once the transaction completed the JobsList would be marked as completed:

Expected behavior

Once a transaction succeeds the program should continue it's work after the await statement

Actual behavior

The await call never completes once a transaction completes.

Steps to reproduce the behavior

Use the code posted above.

Error Logs

It doesn't seem to fall into the catch statement either, so I don't have any error logging.

Gists

---

Versions

• web3.js: 1.0.0-beta.51
• nodejs: npm@6.8.0, Node: v10.11.0
• browser: Latest chrome
• ethereum node: Metamask Ropsten Network

[nivida]

Did you configure the transactionConfirmationBlocks option for your dev environment?
MetaMask is showing confirmed because they do not have a proper transaction confirmation workflow.

Example:

new Web3(provider, null, {transactionConfirmationBlocks: 1});

[jordanmurkin]

I am seeing the same issue in native NodeJS using only web3.

Blockchain node: Local Parity PoA chain (parity version 2.3.9)

const tx = {
  to: "<redacted>",
  value: 123,
  gas: 21000,
  gasPrice: 200000000
};

web3.eth.accounts.signTransaction(tx, privateKey)
.then(signedTransaction => {
  console.log(signedTransaction);

  return web3.eth.sendSignedTransaction(signedTransaction.rawTransaction)
    .on('transactionHash', transactionHash => {
      console.log('txHash', transactionHash);
    })
    .on('receipt', receipt => {
      console.log('Receipt', receipt);
    });
})
.then(receipt => {
  console.log('Receipt', receipt);
})
.catch(error => {
  console.error(error);
});

The on('receipt') and the .then(receipt) never fire, but I can check the status of the transactions on the receipt (looking directly on the node) and it succeeds.

Further info: I have tracing turned on on my dev node. After sending the transaction, the node is continually polled for the receipt, which it returns correctly. The polling continues and never stops repeating:

 jsonrpc-eventloop-1 TRACE rpc  Request: {"jsonrpc":"2.0","id":349,"method":"eth_getTransactionReceipt","params":["0xc0bd0e1bbbde421e438b9af4abf133d6686cd0aa292c7c03eac37eb4aa21cf24"]}.
2019-04-03 14:03:59  jsonrpc-eventloop-1 DEBUG rpc  Response: {"jsonrpc":"2.0","result":{"blockHash":"0x79a72ad275d3be78fc8895275ca88e38097be0d3b9dfdf6fd1ad13ad1353c326","blockNumber":"0x6","contractAddress":null,"cumulativeGasUsed":"0x5208","from":"<redacted>","gasUsed":"0x5208","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","root":null,"status":"0x1","to":"<redacted>","transactionHash":"0xc0bd0e1bbbde421e438b9af4abf133d6686cd0aa292c7c03eac37eb4aa21cf24","transactionIndex":"0x0"},"id":349}.
2019-04-03 14:03:59  jsonrpc-eventloop-1 TRACE rpc  Request: {"jsonrpc":"2.0","id":350,"method":"eth_getBlockByNumber","params":["0x8",false]}.
2019-04-03 14:03:59  jsonrpc-eventloop-1 DEBUG rpc  Response: {"jsonrpc":"2.0","result":null,"id":350}.

After downgrading to version 1.0.0-beta.37 (the previous version I was using), everything works as expected. Trying more versions now

[devedse]

{transactionConfirmationBlocks: 1}

When I try to do this using TypeScript I run into the following error:

Argument of type '{ transactionConfirmationBlocks: number; }' is not assignable to parameter of type 'Web3ModuleOptions'.
  Property 'transactionSigner' is missing in type '{ transactionConfirmationBlocks: number; }' but required in type 'Web3ModuleOptions'.ts(2345)

How would you fix this? Should I create a new TransactionSigner? (And if so, how?)

[nivida]

@devedse Thanks for figuring this out! The transactionSigner property is not defined as optional in the Web3ModuleOptions interface. I will fix and release this today.

Edit:
But yes you are able to pass your custom TransactionSigner.

[devedse]

I'm not sure how to create a TransactionSigner that makes use of MetaMask. If it's not something like a oneliner I'll just wait for your fix :).

[nivida]

@devedse You don't need a custom transaction signer if Metamask is signing them.:)

[devedse]

Yeah I understand, but what do I need to pass to the new Web3ModuleOptions then?

Pardon my lack of JavaScript/TypeScript knowledge. 😄

Edit: Or can you fool typescript into thinking it's all 'okay'?
Edit2: This compiles:

new Web3((window as any).web3.currentProvider, undefined, { transactionConfirmationBlocks: 1 } as any);

[nivida]

You could ignore this with a ts-ignore comment.

Btw.: I've already opened a PR with the fix for the Web3ModuleOptions interface.

[devedse]

I tested it and indeed providing the { transactionConfirmationBlocks: 1 } fixed the issue.