Truffle: Transaction was not mined within750 seconds

[prographo]

Where is it getting 750 seconds from?

I've set timeoutBlocks to 4000, it should carry on waiting.

$ truffle migrate --network mainnet --reset

Compiling your contracts...
===========================
> Everything is up to date, there is nothing to compile.



Starting migrations...
======================
> Network name:    'mainnet'
> Network id:      1
> Block gas limit: 9990259 (0x987073)


1_initial_migration.js
======================

   Deploying 'Migrations'
   ----------------------
   > transaction hash:    0x47e5375210002f4e2a8a751c320138c3432e4d5f889f86675d369cbecd4f4223

Error:  *** Deployment Failed ***

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

[gnidan]

Interesting. That shouldn't be happening. Not sure where it's coming from, can you check Web3.js for that?

Truffle does logic specifically to handle the case of these long timeouts, not sure what's going wrong. Any additional detail you could provide would be helpful! (any reproduction steps; could we see your truffle-config.js?)

[prographo]

Using MacBook / Catalina. Don't think I'm doing anything funky.

$ truffle version
Truffle v5.1.22 (core: 5.1.22)
Solidity - 0.5.8 (solc-js)
Node v12.12.0
Web3.js v1.2.1

     mainnet: {
       provider: () => new HDWalletProvider(mnemonic, `https://mainnet.infura.io/v3/xxx`),
       network_id: 1,       
       gas: 5500000,        
       confirmations: 2,    
       timeoutBlocks: 4000, 
       skipDryRun: true,     
        gasPrice: "5000000000",
       from: '0xXXX'
     },

[haltman-at]

Do you have a way to duplicate this problem consistently? Thank you!

[darkrain]

Have same issue. I try to deploy my erc20 contract,

truffle version Truffle v5.1.25 (core: 5.1.25) Solidity v0.5.16 (solc-js) Node v12.16.3 Web3.js v1.2.1

deployment in ganachi is successful.

[eggplantzzz]

@darkrain Do you have some code or a project that you could share to allow me to reproduce this problem?

[darkrain]

Yes. But i resolve my problem just migrate to openzepellin os

[eggplantzzz]

Closing this for issue maintenance.

[dportabella]

I have the same issue.

Truffle v5.1.31 (core: 5.1.31)
Solidity v0.5.16 (solc-js)
Node v12.18.1
Web3.js v1.2.1

[CruzMolina]

Hey @prographo & @dportabella,

It looks like you are running into web3's default transactionPollingTimeout (750 seconds): https://web3js.readthedocs.io/en/v1.2.9/web3-eth-contract.html#transactionpollingtimeout, which is used with web3's HTTP provider.

truffle doesn't currently support overriding the transaction polling timeout.

To successfully override web3's default transactionBlockTimeout, https://web3js.readthedocs.io/en/v1.2.9/web3-eth-contract.html#transactionblocktimeout (using timeoutBlocks in your truffle-config), you'll need to use a websocket provider.

Hope that helps!

[dportabella]

thx @CruzMolina.

Before I had this truffle-config.js:

const HDWalletProvider = require("truffle-hdwallet-provider");
require('dotenv').config()
module.exports = {
  networks: {
   mainnet: {
      provider: () => new HDWalletProvider(process.env.MNENOMIC, "https://mainnet.infura.io/v3/" + process.env.INFURA_API_KEY),
      network_id: 1,
      gas: 3000000,
      gasPrice: 10000000000*1.15,
      // networkCheckTimeout: 1e9
    }
  }
}

After compiling, it run the dry-run simulation, and then the real deploying, until it failed with "Migrations" -- Transaction was not mined within750 seconds.

This test works fine:

$ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}' https://mainnet.infura.io/v3/a79...
{"jsonrpc":"2.0","id":83,"result":"0x9d882e"}

Now I am trying with:

const HDWalletProvider = require("truffle-hdwallet-provider");
require('dotenv').config()
module.exports = {
  networks: {
   mainnet: {
      provider: () => new HDWalletProvider(process.env.MNENOMIC, "wss://mainnet.infura.io/ws/v3/" + process.env.INFURA_API_KEY),
      network_id: 1,
      gas: 3000000,
      gasPrice: 10000000000*1.15,
      // networkCheckTimeout: 1e9,   // not used?
      // timeoutBlocks: - if a transaction is not mined, keep waiting for this number of blocks (default is 50)  // for wss:
    }
  }
}

but it is blocking forever just after compiling. It does not even start with the dry-run simulation.

Any idea of the problem?

[CruzMolina]

Ah, I believe you're using an older version of hdwallet-provider that does not support websocket provider usage. Try installing and requiring @truffle/hdwallet-provider.

[dportabella]

const HDWalletProvider = require("@truffle/hdwallet-provider");
require('dotenv').config()  // Store environment-specific variable from '.env' to process.env

module.exports = {
  networks: {
    mainnet: {
      provider: () => new HDWalletProvider(process.env.MNENOMIC, "wss://mainnet.infura.io/ws/v3/" + process.env.INFURA_API_KEY),
      network_id: 1,
      gas: 3000000,
      gasPrice: 10000000000
      // networkCheckTimeout: 1e9,   // for https: 
      // timeoutBlocks: - if a transaction is not mined, keep waiting for this number of blocks (default is 50)  // for wss:
    }
  }
}

now it fails with:

$ truffle migrate --network mainnet
Error: ProviderSubprovider - specified provider does not have a sendAsync method

[CruzMolina]

@dportabella , which OS and version of @truffle/hdwallet-provider are you using?

[CruzMolina]

I seem to be running into a different error when attempting to reproduce using the config you shared:

/Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/web3-provider-engine/index.js:219
    number:           ethUtil.toBuffer(jsonBlock.number),
                                                 ^
TypeError: Cannot read property 'number' of null
    at toBufferBlock (/Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/web3-provider-engine/index.js:219:50)
    at /Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/web3-provider-engine/index.js:60:27
    at /Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/web3-provider-engine/index.js:136:12
    at /Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/web3-provider-engine/index.js:199:9
    at /Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/async/internal/once.js:12:16
    at replenish (/Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/async/internal/eachOfLimit.js:61:25)
    at /Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/async/internal/eachOfLimit.js:71:9
    at eachLimit (/Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/async/eachLimit.js:43:36)
    at /Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/async/internal/doLimit.js:9:16
    at end (/Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/web3-provider-engine/index.js:176:5)
    at Object.1593017067515135 (/Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/web3-provider-engine/subproviders/provider.js:19:5)
    at /Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/web3-providers-ws/src/index.js:127:44
    at Array.forEach (<anonymous>)
    at W3CWebSocket.WebsocketProvider.connection.onmessage (/Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/web3-providers-ws/src/index.js:104:36)
    at W3CWebSocket._dispatchEvent [as dispatchEvent] (/Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/yaeti/lib/EventTarget.js:107:17)
    at W3CWebSocket.onMessage (/Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/websocket/lib/W3CWebSocket.js:234:14)
    at WebSocketConnection.<anonymous> (/Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/websocket/lib/W3CWebSocket.js:205:19)
    at WebSocketConnection.emit (events.js:315:20)
    at WebSocketConnection.processFrame (/Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/websocket/lib/WebSocketConnection.js:554:26)
    at /Users/cruzmolina/Code/truffle-projects/reproduce/2020/06/24/test/node_modules/websocket/lib/WebSocketConnection.js:323:40
    at processTicksAndRejections (internal/process/task_queues.js:79:11)

➜  test truffle version
Truffle v5.1.31 (core: 5.1.31)
Solidity v0.5.16 (solc-js)
Node v12.18.1
Web3.js v1.2.1

macOS

➜  test cat package-lock.json | ag -C "hdwallet-provider" | ag -C 1 "version"
    "@truffle/hdwallet-provider": {
      "version": "1.0.35",
      "resolved": "https://registry.npmjs.org/@truffle/hdwallet-provider/-/hdwallet-provider-1.0.35.tgz",

UPDATE: this specific issue has been resolved in #3135. Until this week's release is out, it is available as @truffle/hdwallet-provider@next.

[CruzMolina]

@prographo @dportabella So it appears this is an issue with Infura experiencing heavy network congestion.

Am running into another intermittent issue where truffle's provider network check never receives a response and just hangs.

➜  smoketest truffle migrate --network rinkeby --skipDryRun

Compiling your contracts...
===========================
> Everything is up to date, there is nothing to compile.

[haltman-at]

@CruzMolina So, what do we do about this then? (Also people at the issue maintenance meeting are wondering how you came to this conclusion.)

[CruzMolina]

@haltman-at For this specific issue, we can allowing users to configure web3's transactionPollingTimeout (the current default is 750 seconds): https://web3js.readthedocs.io/en/v1.2.9/web3-eth-contract.html#transactionpollingtimeout, which is used with web3's HTTP provider.

The earlier issue mentioned here and in #3130 has been resolved in #3135, and the issue mentioned here and in #3133 has been resolved in #3134.

[hannymaharani99]

I still have this kind of issue, does anyone can help me how to override or configure transactionPollingTimeout so I can deploy my contracts?

[dportabella]

As a workaround, I manage to deploy my contract by increasing the gas price. Indeed I had a too low value. The bigger the price, the faster the transaction. Note that gas price is crazily high these days: 70 Gwei per gas.
https://ethgasstation.info/

[interfect]

I ran into this issue as well, with transaction 0x604d0e4d1ea1bc94868cb2dd11409b586a02d156da45d62e1e5967a185c43663.

Since the transaction eventually went through (and cost a fair bit of money), how do I manually update the JSON files and the on-chain migration contract to reflect the successful deployment that Truffle didn't wait for? Is there a way to hack my migrations script temporarily to tell Truffle to work with an existing transaction instead of making a new one at deployer.deploy?

[rmourey26]

*UPDATE
I was able to push the deployments through by adjusting gwei to 47 and gas to 3700000. Waiting for final confirmation. Ultimately issue explained below required a deployer balance of ~2.5 times actual and final deployment cost. ****

---

ORIGINAL MESSAGE BELOW >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Upgradeable ERC20 OpenZeppelin Contracts v 3.3.0
VS/Code WSL2 with Docker/Ubuntu backend
Truffle Global 5.1.58
NodeJS 13.14 via NVM
Ganache 6.12
Solc - 0.7.5 (downloaded and designated in truffle-config.js
Alchemy Provider (mainnet)
InfuraProvider (ropsten test)
NVM to NPM node path match
*3 contract deployment*

Is anyone working on this issue?? I have had the same thing going on for the last couple days(timeout at precisely 750 seconds) In conjunction with the repeated erroneous 750 second timeouts, Truffle appears to also have issues with deployer account balances while processing multiple contract deployments. To be clear, I receive either a 750 second timeout, OR I receive incorrect notification of an insufficient balance. After Truffle deploys the 1st of 3 contract deployments, Truffle miscalculates the total cost of subsequent deployments and inaccurately deems the deployer account balance as insufficient. Lets say we have 3 deployments in the following hypothetical transaction...

-----15,000,000 WEI beginning balance of deployer account X
----12,000,000 WEI total transaction cost determined by Truffle
----- 4,000,000 WEI per deployment

The first deployment processes as projected thus leaving a balance of 11,000,000 wei in account X. Truffle then looks at the remaining deployments assuming that the first deployment was never 'paid for' and tells the user that the total deployment cost remains 12,000,000 WEI but also substracts the cost of the first deployment from account X. And then deems that the sender does not have enough for the rest of transaction. Doesnt make sense right?

Check out my screen shots attached herein. My Metamask account (deployer account) balance clearly shows that it would cover the upfront cost while paying 70 GWEI for the transaction The upfront cost correlates to (gasPrice * gas) listed in my config file which is also picutured in this post. The first deployment occurs, Truffle then subtracts the cost of the first deployment (in this case being ~ 0.065 ETH) from my deployer account thus leaving my account balance at .23624 ETH.

The second deployment begins processing and Truffle again looks at the INITIAL deployment cost and uses that now inaccurate figure to make the decision to stop the deployment because the deployer account balance is insufficient. Now because of this apparent issue, the only means a user has to get passed the first deployment and finish full deployment is by adjusting the gas price in the config file (which is the GWEI in the tranaction) to such a low amount that the deployment times out because there isnt enough GWEI included and miners wont touch the transaction at that price. Does this make sense? If I am missing something with this, please let me know because I'd like to get these contracts deployed to mainnet as they should have been several days ago.

In my opinion, Truffle has a significant opporuntity for improvement in the documenation and deployment area in general. But that is something I will address separately and at later time.