Tx never resolves on ganache and no confirmation or receipt event triggered beta50-52

[szerintedmi]

Description

A tx never resolves on ganache. sendTransaction, sendSignedTransaction and confirmation events are NOT triggered.
Only transactionHash event is triggered.

It seems the web3 tx is somehow blocking ganache's automatic mining. It works in beta36 (our current version): ganache is mining blocks and confirmations are received.

NB: I tried to call evm_mine manually from confirmation event or even before await tx but it is not executed just when the tx times out

Expected behavior

This should work on ganache as per documentation:

const receipt = await dummyContract.methods.revertMe().send()
  .on("transactionHash", <it works:  triggered with tx hash>)
  .on("receipt", 
     <should be triggered with tx receipt>)
  .on("confirmation", 
      <should be triggered for each confirmation with 
             confirmation number and with tx receipt>)
 // receipt should resolve after transactionConfirmationBlocks 

Actual behavior

• txHash recevied
• no receipt or confirmation event called
• the tx never resolves

Steps to reproduce the behavior

https://github.com/Augmint/web3js_integration_tests/blob/master/test/sendTransaction.js
https://github.com/Augmint/web3js_integration_tests/blob/master/test/signTransaction.js
https://github.com/Augmint/web3js_integration_tests/blob/master/test/fails.js

Error Logs

N/A

Gists

Barebone gist to demonstrate the issue:
sendTx.js

Versions

• web3.js: beta52
• nodejs: 8.15.3
• browser: N/A
• ethereum node: ganache-cli v6.4.1

[nivida]

Thanks for referencing the other issue I have to close. Setting of the transactionConfirmationBlocks option over the module options of Web3 will solve your issue.

It was working before over an HTTP connection because the transaction confirmation workflow was not enough good.

[szerintedmi]

@nivida : I have the transactionConfirmationBlocks set and also crosschecked as I mentioned in the other issue

It works fine in earlier versions and I might be doing something incorrectly with the new but I can't figure out what.
I created a barebone gist to demonstrate the issue:
sendTx.js

I tried to remove node_modules and fresh install, I tried to run ganache without yarn, no luck

Do is it work for you?

sendTx.js output (hangs forever):

)$ node ./sendTx.js
WebsocketProvider version: 1.0.0-beta.52 web3.eth.transactionConfirmationBlocks: 3 web3.transactionConfirmationBlocks: 3
on transactionHash 0xb3470307f363a79f64f098bace0387fe1591eedb0e10ee321e26110567f7f880

Ganache output

$ yarn ganache-cli
yarn run v1.13.0
$ web3js_integration_tests/node_modules/.bin/ganache-cli
Ganache CLI v6.4.1 (ganache-core: 2.5.3)

Available Accounts
==================
(0) 0xf22ac8bc7fe1fb9aee6bc4a27d110f3f06184a91 (~100 ETH)
(1) 0x5c150b1e0bbe5d26721c6364a4b94342c3579936 (~100 ETH)
(2) 0x5e9e14c29290c0efcdf7ece3de20ff333e864cad (~100 ETH)
(3) 0x75fcba2fa272c82048bf462a4be3bdc7e91282f4 (~100 ETH)
(4) 0xaac098538a624b058e7a3b14c795bcf250b1df5a (~100 ETH)
(5) 0xfde38ce7ee6f7f94b550224168cb3debd7e19262 (~100 ETH)
(6) 0xc7236804cc0a03019744e13137da8440c83972d5 (~100 ETH)
(7) 0x22891105af22e15f6383eda8f2a31218437b9e06 (~100 ETH)
(8) 0xa3c7440e6d96cbad9137bf97e996a0e688108a46 (~100 ETH)
(9) 0xca53b057e1a7ed7782e43725e4ffe77d7c526667 (~100 ETH)

Private Keys
==================
(0) 0xc86b4b02c4216fa9a1a149d760e678e72562959fd067d2fe7cab3e06371d0668
(1) 0xe956348ff38c82a025dc53ffc1390b48c42beed2b06c254628814a4d567109fd
(2) 0x1e9108d5d9f12d799a665b9ca477694857170497b356a1e29c527ae855ef63b9
(3) 0xbf0e4089d48ab1ae3e24ef932dbe33cc390f9756d588fd03ffa546aea9a48a57
(4) 0x32b9b54da7da7a39460a75c3eee902945e234d796f72b69c8852d9bfeef524ff
(5) 0x2296843b69cab94bd9c29c5fd55cb54a08d0da2fa51b67c5486c4973a3ec2a55
(6) 0xab0261a5ea65813ad0df3d909ba1aa4ab1df25666eae8c642c8deed067df0215
(7) 0xd20475e6594de95632385b4f9955d322eb30d249ed4f302acb2329f7d003fcea
(8) 0xdf021f7431b387a2fa5e4070a752c7e463dc71bba84e4dff5690fb25522abf7f
(9) 0x4b9cbfd60da467145ca51a9448cab9f958c5b020bb1521441bb441812dbc8349

HD Wallet
==================
Mnemonic:      body time crane foam extra patient give return fall such build hamster
Base HD Path:  m/44'/60'/0'/0/{account_index}

Gas Price
==================
20000000000

Gas Limit
==================
6721975

Listening on 127.0.0.1:8545
eth_accounts
eth_gasPrice
eth_sendTransaction

  Transaction: 0xb3470307f363a79f64f098bace0387fe1591eedb0e10ee321e26110567f7f880
  Gas usage: 21000
  Block Number: 1
  Block Time: Fri Apr 05 2019 09:44:08 GMT+0100 (British Summer Time)

eth_subscribe

EDIT: just tried with Ganache CLI v6.2.5 (ganache-core: 2.3.3), same issue

[princesinha19]

@szerintedmi In my case, it's working fine both with Ganache and Geth so, you need to test at your end. It's not the problem with web3 v1.0.0-beta.52.

You can see my ganache:

[szerintedmi]

thanks @princesinha19 !
What are you running it on? (I'm on OSX Mojave, node 10.15.3)
Would you mind sharing your code?

[princesinha19]

I am using Linux (Ubuntu 18.04).

// Defining New Contract 
let myContract = new web3.eth.Contract(abi);

// Deploying contract using Web3
await myContract.deploy({
	data: '0x' + bytecode,
	arguments: []
}).send({
	from: walletAddress
	gas: 
}).on('receipt', (receipt) => {
        console.log(receipt)
});

[szerintedmi]

@princesinha19 : ah, that's a deploy not sendTransaction. I'm going to test with that soon.
what's your node version? I just downgraded to 8.15.1 (from 10.15.3) but same issue.

would you mind trying to run this (should work on fresh ganache)?
https://gist.github.com/szerintedmi/251b5d5739888ad595548625c8d5d424

UPDATE: neither deploy contract works: https://gist.github.com/szerintedmi/57e89261b67a4469626579427ffe1ec8

[szerintedmi]

It broke somewhere in beta49, went back with versions one by one and my test script resolves with beta48 and but same issue with 49:

$ node ./sendTx.js 
WebsocketProvider version: 1.0.0-beta.48 web3.eth.transactionConfirmationBlocks: 24 web3.transactionConfirmationBlocks: 24
on transactionHash 0x5c55387da5ad0f5668e86766a53111a625226fb145deee4303d1aa416682e629
on receipt
Got receipt

(although confirmations are not coming)

[princesinha19]

@szerintedmi Upgrade to version 1.0.0-beta.52.

[szerintedmi]

@princesinha19 : I'm on beta52.
I identified in which release this broke. And it is working with beta48 but not any version after, even beta52

Does the script I linked works for you?

[szerintedmi]

We tried to run it in different environments but same result. I reopened this issue with focusing only on the WebsocketProvider behaviour: #2661

[levino]

I have this issue with the metamask provider. First of all the PromiseEvent returned by send() resolves now on confirmation not on receipt. The docs are now outdated. Second when you initialise Web3 you have to tell web3 after how many confirmations the transaction created by send() should be considered confirmed (and as such the promise will be resolved). By default this number is infinity. So you need to do this:

const web3 = new Web3(myProvider, undefined, {
  transactionConfirmationBlocks: 1,
})

I can hardly imagine that this behaviour is intentional. Reverse engineering this is like a bad acid trip.

[levino]

I also suspect that this causes another issue: Parallel transactions do not work any more. Before a "send transaction" would immediatly resolve with a receipt and the local nonce would be increased. Now the "send transaction" will only resolve after at least 1 confirmation. If one attempts to send another transaction before the last one has been confirmed (and as such the promise has been resolved and the local nonce cache updated) one will send another transaction with the same nonce which will be rejected.

[szerintedmi]

I also suspect that this causes another issue: Parallel transactions do not work any more. Before a "send transaction" would immediatly resolve with a receipt and the local nonce would be increased. Now the "send transaction" will only resolve after at least 1 confirmation. If one attempts to send another transaction before the last one has been confirmed (and as such the promise has been resolved and the local nonce cache updated) one will send another transaction with the same nonce which will be rejected.

Same here I just didn't want to convolute #2661 more. If I call sendTransaction or evm_mine from the same process it doesn't execute until the other resolves. Maybe worth a new ticket?

[pepoospina]

@levino , maybe setting transactionConfirmationBlocks = 0 would make the send resolve soon enough for parallel transactions?