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

[vbaranov]

[email protected]
Contract deployment with MetaMask 3.10.9: https://etherscan.io/tx/0xccec451b8a66dc3a44318cd45924893715564e7758245031ef9700acbb21d127

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

[pannous]

yes, seams to be a horrible bug.
also you paid ($3.06) just tx cost!

[DSalko]

Can this be related to Infura? I see this a lot on testnet too.

[adonley]

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.

[wcw84]

I have found the same problem in the main chain. Everything seems OK, but this errors just jump out. How to fix it?

[adonley]

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.

[Freydal]

Is there anything I can do to increase the likelihood of successful subscribe? I am seeing this issue across multiple projects intermittently.

[adonley]

I can take a look at it in the next few days and see about a pull request. I'm not actively using web3 on a project at the moment so it's going to take me a bit. If anyone else starts this lmk.

[utkarsh17ife]

Any updates on this?

[MaggieNgWu]

Same problem

[devdany]

same problem.
Have you received a transaction with a transaction and received this error or a transaction without this error?
my transaction is not contained in mainnet.
in testrpc, no problem. but in mainnet, i get this error

[MaggieNgWu]

I turn to use "truffle-contract" module, it run smoothly now.

Original code use web3 to deploy contract get error "ransaction was not mined within 50 blocks":

var newDC = new web3.eth.Contract(DContract.abi);
    newDC.deploy({
        data:DContract.bytecode ,
        arguments: arg
    }).send({
        from: account,
        gas: 4000000,
        gasPrice: 30000000000000
    },function(error,transactionHash){
        console.log(error);
        console.log('Ethreum transaction', transactionHash, 'successfully posted.');
    }).then(function(newContractInstance){
        //const SC = new web3.eth.Contract(SContract.abi,config.ethereum.summary);
        alert("Contract Address : "+newContractInstance.options.address); // instance with the new contract address
    });

Turn to use truffle-contract runs well, I don't know why.

var TruffleContract = require("truffle-contract");
var Web3 = require('web3');
var provider = new Web3.providers.HttpProvider(config.ethereum.ipcrpc);
const DCJSON = require('./../../contracts/DataContract.json'); 

var arg=[.....]
createDataContract(arg).then(function(instance){
    console.log(instance.address);
},function(err){
    console.log(err);
})

function createDataContract(arg){
    return new Promise(function(resolve,reject){
        var DContract = loadContract(DCJSON, provider, account);
        DContract.new(arg[0],arg[1],arg[2],arg[3],arg[4],arg[5],arg[6],arg[7]).then(function(newDc){
            resolve(newDc);
        }).catch(function(err){
            reject(err);
        });
    })

}
function loadContract(contractjson, provider, address) {
    let contract = TruffleContract(contractjson);
    contract.setProvider(provider);
    if (typeof contract.currentProvider.sendAsync !== "function") {
        contract.currentProvider.sendAsync = function() {
            return contract.currentProvider.send.apply(
              contract.currentProvider, arguments
            );
        };
    }
    contract.defaults({ from: address, gas: 4500000 });
    return contract;
}

[zaro]

I can confirm the same issue when using version 1.0.0-beta.27 , metamask and the following code:

  const contract = new web3.eth.Contract(abi);
  const p = contract.deploy({
      data:bytecode,
      arguments: params,
  })
  .send({
      gas: gasEstimate,
      gasLimit: 4000000,
      from: fromAddress,
   })
  .catch(e=> {
    console.error('deployContract error', e);
    dispatch(deployError(contractName, e));
    throw e;
  })
  .then(function(newContractInstance){
    if(newContractInstance){
      console.log(`${contractName} Adress`, newContractInstance.options.address);
      dispatch(deployComplete(contractName, newContractInstance.options.address));
    }
    return newContractInstance;
  });

This fails on both rinkeby and my private chain, and the failures seem random, e.g. sometimes the contract is deployed and sometimes it fails with this error.

[strelok1]

Yep, this is extremely annoying especially in this time of network congestion while using Infura that is taking on average 5 mins to even broadcast the transaction. @adonley have you been able to patch it locally?

[floriancastelain]

We have the same problem here on a private chain and a contract deployment with a signedTransaction and web3js. If any stable solution (not changing library code would be great :D ), please share :)

[Freydal]

It is my understanding that the then and confirmation PromiEvent are the components effected by this error.

This for example is an implementation that may be effected:

transaction.send(options).then((receipt) => { doSomething() });

This alternative should execute properly but is much more verbose:

let txHash;
transaction.send(options).once('transactionHash', hash => txHash = hash).then((receipt) => {
  doSomething()
}).catch((e) => {
  if(e.includes('not mined within 50 blocks')) {
    const handle = setInterval(() => {
      web3.eth.getTransactionReceipt(txHash).then((resp) => {
        if(resp != null && resp.blockNumber > 0) {
          clearInterval(handle);
          doSomething();
        }
      } 
    });
  }

[floriancastelain]

Thank you for that. Will try it as soon as possible!

[kn1g]

Hi, get the same error ().

I use infura and set up a raw transaction and basically try to send it with:

const Web3      = require('web3');
const Tx        = require('ethereumjs-tx');
var web3 = new Web3(new Web3.providers.HttpProvider("https://mainnet.infura.io/KEY"));

const txData = {
                    nonce:      web3.utils.toHex(txCount),
                    value:      '0x0', 
                    from:       addressFrom,
                    gas:        web3.utils.toHex(req.body.maxGas),
                    gasPrice:   web3.utils.toHex(req.body.gasP), 
                    to:         myContract._address,
                    data:       myContract.methods.transfer(req.body.AddressTo, TokenAmount).encodeABI(),  
                }

sendSigned(user.privKey, req, txData, function(err, result) {
                    if (err) return console.log('error', err);  
                    console.log('sent', result);
                });

function sendSigned(encPrivKey, req, txData, cb) {
    const privateKey  = new Buffer(privKey, 'hex');
    const transaction = new Tx(txData);
    transaction.sign(privateKey);
    const serializedTx = transaction.serialize().toString('hex');
    web3.eth.sendSignedTransaction('0x' + serializedTx, cb);
}

gives me the TxHash but

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

And transaction is not mined.

Edit.:
Turned out that the gas limit was way too low. But than this error is completely misleading :/

[floriancastelain]

@kn1g Can you say what was your gas limit? I'm a 4 millions for now, which seems way enough for that :S

[kn1g]

I raised the gas limit to 160000 for a simple transaction. It seemed to work - but the error is still annoying...
4 Million is really a lot. What is the block gas limit atm?

[floriancastelain]

Blick limit is 4.7 millions. With more investigation, it seems like my transaction is not correct, I cannot estimate the gas cost of it.

[kn1g]

I also had trouble estimating it. It actually seems to work for plain transactions. But if you estimate it for a contract call it may take a LONG time or just times out.

I'm using infura.io. In the end I just removed the estimate gas function and replaced it with hardcoded default values for different scenarios... :/

[stefanbinder]

Same here, I'm able to deploy my Greeter Tutorial contract but not more.

With other contract for a real token, I get different errors like that mentioned.
As well:
Unhandled rejection Error: Returned error: exceeds block gas limit
Unhandled rejection Error: The contract code couldn't be stored, please check your gas limit.
Unhandled rejection Error: Transaction was not mined within 50 blocks, please make sure your transaction was properly send. Be aware that it might still be mined!

Not sure whats the cause.
The build-script with web3 for the greeter and token-contract is the same, so I guess its the contract itself?

[woniesong92]

Same here

[onairelav]

idem

just to see the receipt it's possible to comment the code inside the catch that raise the error

t/node_modules/web3-core-method/src/index.js

[daniel-van-niekerk]

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?

[TrejGun]

same here

[zachgoll]

+1 on this. Running 1.0.0-beta.26 getting this error while using infura on Ropsten. Contracts will deploy fine, but error is thrown in promise catch.

[adonley]

This issue is woven into the web3-core-method package. There is a mix of ideas - one of pub/sub (you get a block) and one of an interval set (polling every second) which use the same catch block. We'd have to make another request to check and compare block number changes when we're doing the interval in order to prevent this from happening in 50 seconds. I'm not sure if the fix is worth the second RPC. Maybe we just make the timeout longer for polling.

[woniesong92]

+1. Any movement on this?

[adonley]

Check above pull request.

BTW this should only happen if the network is at capacity or when using a low gasprice. 50 seconds is enough for about 3 blocks to be solved.

[woniesong92]

@adonley thanks for the PR. To add information, I am encountering the error very consistently using the gas price suggested by https://ethgasstation.info.

[frozeman]

Please test this against latest beta.31

[justindthomas]

So far so good!

[mckapur]

Even though this isn't broken on beta.31, I'm seeing an issue where I deploy a contract and -- even though the contract successfully deployed -- I'll get an error saying "The contract code couldn't be stored, please check your gas limit"

[adonley]

Try looking at https://github.com/trufflesuite/truffle/issues/476 .

[NoChance777]

+1 Join to same issue. Why you guys don't make up it configurable?

[CQBinh]

Same on bate.34, ropsten test net.

[adonley]

Web3 is mostly not configurable beyond the provider.

@CQBinh why not use a higher gasprice to be included in a block within 750 seconds on ropsten?

[CQBinh]

@adonley I have increased the gas limit to 3,000,000 with no luck, both beta.31 and beta.34.
Here is my code:

var contractAddress = '0xd4...';
var txOptions = {
  nonce: web3.utils.toHex(web3.eth.getTransactionCount(address)),
  gasLimit: web3.utils.toHex(3000000),
  gasPrice: web3.utils.toHex(99000000000),
  to: contractAddress
}

var destinationAddress = '0xa91...';
var tokenQuantity = 69;
var rawTx = txutils.functionTx(interface, 'transfer', [destinationAddress, tokenQuantity], txOptions);
sendRaw(rawTx);

And the sendRaw function:

var address = '0xa98...';
var key = 'a84...';

function sendRaw(rawTx) {
  var privateKey = new Buffer(key, 'hex');
  var transaction = new tx(rawTx);
  transaction.sign(privateKey);
  var serializedTx = transaction.serialize().toString('hex');
  web3.eth.sendSignedTransaction(
    '0x' + serializedTx, function(err, result) {
      if(err) {
        console.log(err);
      } else {
        console.log(result);
      }
    }).on('receipt', console.log);
}

[CQBinh]

Finally found out my issue, the web3.eth.getTransactionCount(address) is async, so I have to await or use callback or promise to get the transactionCount.

[thinhlvv]

The same issue here with [email protected]

Transaction was not mined within750 seconds, please make sure your transaction was properly sent. Be aware that it might still be mined!

I tried many options to remove but it's still there:

• Add nonce to raw transaction
• Increase gas Price/gas limit.

[CQBinh]

@thinhlvv when connecting to the testnet, you maybe provide the exact chainId (Ropsten is 3, took from docs).
Take a look on my code:

web3.eth.getTransactionCount(address).then(txCount => {
  var txOptions = {
    chainId: 3,
    nonce: web3.utils.toHex(txCount),
    gasLimit: web3.utils.toHex(51000),
    gasPrice: web3.utils.toHex(41e9),
    to: contractAddress
  }
  console.log('txOptions', txOptions)
  var destinationAddress = '0xa';
  var tokenQuantity = 69e18;
  var rawTx = txutils.functionTx(interface, 'transfer', [destinationAddress, tokenQuantity], txOptions);
  sendRaw(rawTx);
});

[thinhlvv]

@CQBinh Yes, I noted the chainID. I got this problem in mainnet. I ran for days, then this error appeared.

[CQBinh]

@thinhlvv Is there the problem in the GAS limit, did you tried to increase it?

[dbryan0516]

I encountered the error
Transaction was not mined within750 seconds, please make sure your transaction was properly sent. Be aware that it might still be mined!

While using a private chain with geth/poa/5second blocks and trying to call a smart contract function.

I was using the lastest block's gasLimit as the gasLimit for the tx I was creating. The issue stems from the block's decreasing gasLimit as the block tries to approach the targetGasLimit that was used to create the chain. In my case (and mainnet), the targetGasLimit was 4,712,388 but the genesis block's gas limit was extremely higher, causing blocks to have a decreasing gas limit until it reached close to the targetGasLimit.

So by using the latest Block's gasLimit, by the time my tx was sent, the new block gasLimit had decreased. For some reason this never threw a "Exceed's block gas limit" error, so the tx just sat, perpetually waiting.

This was in a blockchain 101 application, very small and local app. So I would be the only one sending tx's, i didn't know how much gas would be used (estimate=infinite), so I set it to the 4.7million targetGasBlock and this seems to have fixed for now.

I'm curious as to why no other error was thrown, like "Exceeds block gas limit"

using 1.0.0-beta.34

[NicolaOrritos]

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.

[cosander]

@NicolaOrritos: Thanks for the tip, downgrading to 1.0.0-beta.34 worked for me (also with private chain with PoA and other contracts could be deployed though).
Hope this is going to be fixed sometime soon.

[NicolaOrritos]

@cosander glad it helped.
In general I also hope the developers will make web3.js return proper messages when errors occur.

[nivida]

@NicolaOrritos I've planned to create more specific error messages. I had a look on the winston logger but I think I will implement a simple logger class by my self and improve the messages. If it makes you wonder what I'm working on right now then check out this PR https://github.com/ethereum/web3.js/pull/2000

[ltfschoen]

I encountered the same error Error: Transaction was not mined within 50 blocks, please make sure your transaction was properly sent. Be aware that it might still be mined! when I'd run tests that I'd written with truffle test when was running a development chain, and where I was explicitly specifying a block time with ganache-cli --blockTime 3. I resolved the error by omitting the block time flag (i.e. just running ganache-cli) so the blocks would be mined instantly

[aenhsaihan]

Is this really resolved? I'm still getting the same error on 1.2.2

I get the error when I used Kovan testnet just now. But for local development with instant mining, the await function never returns so the page just shows the transaction as still processing.