Solvedweb3.js Transaction was not mined within 50 blocks, please make sure your transaction was properly send. Be aware that it might still be mined!

web3@1.0.0-beta.22
Contract deployment with MetaMask 3.10.9: https://etherscan.io/tx/0xccec451b8a66dc3a44318cd45924893715564e7758245031ef9700acbb21d127

Transaction mining duration was approximately 2 mins and only 3 - 5 blocks were generated before it was mined.
Why does web3 think, that it was 50 blocks and it catches an error here? is this a bug?

53 Answers

✔️Accepted Answer

I think I found the error. When I call a contract function and "await" the send, startWatching is invoked from the file web3-core-method/src/index.js . I didn't achieve a pub/sub so a 1 second interval is set. Every time this 1 second interval passes return (existingReceipt ? promiEvent.resolve(existingReceipt) : _ethereumCall.getTransactionReceipt(result)) is called and we don't have an existing receipt so getTransactionReceipt with a txhash which is valid. But it hasn't been included yet so if (!receipt || !receipt.blockHash) {throw new Error('Receipt missing or blockHash null');} is invoked and the catch at the bottom of the statement increments a timeout. After 50 tries, this error is achieved. This 50 tries is supposed to be reserved for 50 blocks.

Found this running a private chain testing some code. Let me know if I can provide additional info.

Other Answers:

I needed to quick fix so I commented out the code in the catch for now. If I have time I will try to pull request it but this one is interesting because two different timeout ideas are clashing.

From the directory where node_modules is located you can run: sed -i '/(timeoutCount - 1 >= TIMEOUTBLOCK)/,+4 d' node_modules/web3-core-method/src/index.js and it will delete out the timeout.

Please test this against latest beta.31

Using 1.0.0-beta.27. This happens consistently but the transactions are mined normally.
I'm not deploying a contract here, just call a ERC20 token contract's transfer function.

This error is interfering with my error handling for actual errors. Is there no update or more info on this issue?

This bug is still present in 1.0.0-beta.36, but NOT in 1.0.0-beta.34.
Found while working on a private chain with PoA.
Worked around pinning to 1.0.0-beta.34 in my package.json.

More Issues: