truffle icon indicating copy to clipboard operation
truffle copied to clipboard

truffle migrate --network rinkeby Time Out # Error: PollingBlockTracker - encountered an error while attempting to update latest block:

Open BlockchainsFans opened this issue 4 years ago • 78 comments

  • [ ] I've asked for help in the Truffle Gitter before filing this issue.

Issue【Error: PollingBlockTracker - encountered an error while attempting to update latest block:】

I'm going to be bullied by this damn truffle and I'm going crazy! I tried to deploy to the test network through truffle migrate --network rinkeby --reset --compile-all, and also tried to switch between various truffle versions and node versions, but the timeout has been displayed for three days, and I ping https in cmd ://rinkeby.infura.io/v3/myKey but it shows that it has timed out, so I purchased a VPN, but unfortunately I can come here to ask the gods, but I cannot connect to my https://rinkeby.infura .io/v3/myKey🤢.. . . . And I found through IP address search that the ip address of my infura is constantly changing 😂🤣 (I am in China, I don’t know if your infura is like this). So, my question is: now how do I deploy truffle to the rinkeby test network? ? I think it is possible that Truffle v5.1.33 has a bug Finally, I offer a reward of 0.0001ETH, if someone can help me deploy my solidity to rinkeby through truffle! What the issue is, in broad strokes.

Steps to Reproduce

Please provide the shortest amount of steps to reproduce your issue.

Expected Behavior

What you expected to happen.

Actual Results

What actually happened. Please give examples and support it with screenshots, copied output or error messages.

Environment

  • Operating System:
  • Ethereum client:geth 1.9.21-stable Go Version: go1.15
  • Truffle version (truffle version): Truffle v5.1.33 and 4....some
  • node version (node --version): 8.11.1 and 14.0.0 and 10....some
  • npm version (npm --version): node comes with.....E.g 6.9.0

BlockchainsFans avatar Sep 12 '20 10:09 BlockchainsFans

seeing this exact problem. I've been days working on solving this without success...

My error stack:

Starting migrations...

Network name: 'rinkeby' Network id: 4 Block gas limit: 10000000 (0x989680)

1_initial_migration.js

Replacing 'FakeHEGIC'

transaction hash: 0x85f66f943a44c19a112e61378e7f56418d408b4d273f042808c22977fd5e4f1c ⠴ Blocks: 0 Seconds: 5Error: PollingBlockTracker - encountered an error while attempting to update latest block: Error: getaddrinfo ENOTFOUND rinkeby.infura.io at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:64:26) at PollingBlockTracker._performSync (/Users/-/Projects/DeFi/hegic/hegic-contracts-v2/node_modules/eth-block-tracker/src/polling.js:51:24) at processTicksAndRejections (internal/process/task_queues.js:97:5)

My Truffle Version: Truffle v5.1.44 (core: 5.1.44) Solidity - 0.6.12 (solc-js) Node v12.16.1 Web3.js v1.2.1

Connectivity works fine, tried flushing dns, restarted computer, router, ... and still not working.

This error shows up pretty randomly, almost always causing a problem in the middle of a complex (several contracts) migration. It may end up deploying the whole thing. When testing long contracts (truffle test --network rinkeby), it almost never finishes the whole list of tests to be done.

jmonteer avatar Sep 13 '20 17:09 jmonteer

Hmm weird. It sounds like it might be some kind of inconsistency on Infura's part. Can you reproduce this issue reliably? If so, can you provide steps for us to try and reproduce this so we can troubleshoot? Thanks!

eggplantzzz avatar Sep 16 '20 17:09 eggplantzzz

@eggplantzzz I am pretty sure this has something to do with Infura's responses. This is not a deterministically reproducible issue. It fails after some txs (with some simple contracts it works sometimes because fewer txs = less probability of failing)

I am pretty sure this comes up when infura returns empty responses.

I have got this error using (https://github.com/jmonteer/simplecontract), which is a simple project to check if it was something wrong on my code, which I believe is not. If this does not fail when you first run "truffle test --network rinkeby", try running it several times, it will fail eventually.

In my repo's truffle-config.js you will see 3 different networks: rinkeby, rinkeby_alchemy and test. I got it working with test and sometimes with rinkeby (Infura's provider). rinkeby_alchemy always throws a 429 error... (too many requests).

Btw, it worked before (early August), although I have not been able to downgrade packages to make it work again.

THanks!!! I will be available if you need more details.

jmonteer avatar Sep 16 '20 21:09 jmonteer

I am facing the same issue. My project has 10 contracts and a couple of them are fairly complex and I haven’t been able to deploy them on any of the test networks. A ETIMEDOUT error comes up every time.

kallolborah avatar Sep 17 '20 17:09 kallolborah

Can you post your package.json & truffle-config.js?

jmonteer avatar Sep 17 '20 17:09 jmonteer

@jmonteer here they are https://github.com/verified-network/via-issuer/blob/master/package.json, and https://github.com/verified-network/via-issuer/blob/master/truffle-config.js

kallolborah avatar Sep 17 '20 17:09 kallolborah

@eggplantzzz any news regarding this?

jmonteer avatar Sep 17 '20 18:09 jmonteer

@eggplantzzz any news regarding this?

nobsu avatar Sep 18 '20 09:09 nobsu

Not yet, I'll try and reproduce it today to troubleshoot. I'll let you know if I come up with anything.

eggplantzzz avatar Sep 18 '20 14:09 eggplantzzz

By the way, @jmonteer you shouldn't put your infura key and mnemonic under version control as other people will be able to use it. You should only keep those locally!

eggplantzzz avatar Sep 18 '20 14:09 eggplantzzz

Hey! Thanks. This is on purpose as this is a test environment and test wallets. Only used by this project. I wanted the first person to have exactly the same conditions I had, as I did not find anyone with the same issue.

But thanks! I appreciate you telling me.

Keep us updated about any progress.

jmonteer avatar Sep 18 '20 15:09 jmonteer

@jmonteer So I was able to successfully migrate your project 4 times in a row. Also @kallolborah I was able to fully migrate your project to Ropsten as well though it took a long time. Maybe your connections are not as fast or something. I'm not sure! This will certainly be difficult to troubleshoot if it is not reproducible. Perhaps you could try migrating from a different connection that you know to be faster to see if you can reproduce it.

eggplantzzz avatar Sep 18 '20 15:09 eggplantzzz

@eggplantzzz thanks for checking this out. I did try with different connections. I tried again just now with one with a 20 Mbps upload speed but I see that it just gives the timed out error immediately after the contracts are compiled during migration. It's not as if it takes time to time out ! Do you see any thing in my package.json that could cause this ? I had earlier seen this issue and thought what I am seeing could be related. I hope I am not using any faulty dependencies.

kallolborah avatar Sep 18 '20 16:09 kallolborah

also fyi @eggplantzzz this is what I get

C:\Engineering\Via\via-issuer\node_modules\request\request.js:848
          var e = new Error('ETIMEDOUT')
                  ^
Error: PollingBlockTracker - encountered an error while attempting to update latest block:
Error: ETIMEDOUT
    at Timeout.<anonymous> (C:\Engineering\Via\via-issuer\node_modules\request\request.js:848:19)
    at listOnTimeout (internal/timers.js:549:17)
    at processTimers (internal/timers.js:492:7)
    at PollingBlockTracker._performSync (C:\Engineering\Via\via-issuer\node_modules\eth-block-tracker\src\polling.js:51:24)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at runNextTicks (internal/process/task_queues.js:66:3)
    at listOnTimeout (internal/timers.js:518:9)
    at processTimers (internal/timers.js:492:7)

kallolborah avatar Sep 18 '20 16:09 kallolborah

I can deploy to a truffle teams sandbox (not using HDWalletProvider) so it should not be a problem of connection, right? This only comes up when Infura and HDWalletProvide are involved and infura sends empty blocks for some reason (maybe has to do something with connection?)

What should be a good alternative to HDWalletProvider? I could try to connect to rinkeby using other solutions and isolate the issue.

Also, Have you tried to truffle test my project? When you try to deploy / test complex contracts and need to send lots of txs is when it fails...

jmonteer avatar Sep 18 '20 22:09 jmonteer

I finally could migrate my project to ropsten. I changed to using web sockets, and set a 'networkCheckTimeout' attribute to the ropsten network in truffleconfig and it worked. Without networkCheckTimeout, the migration was not happening using either https or wss. And even with networkCheckTimeout set, the migration did not happen on https, for whatever reason that I do not understand.

kallolborah avatar Sep 20 '20 06:09 kallolborah

@jmonteer Are you able to deploy to a Truffle Teams sandbox using HDWalletProvider?

@kallolborah Ah ok, so those network tweaks worked for you. Looks like it just needed a bit more time I guess. Glad it got sorted!

eggplantzzz avatar Sep 21 '20 17:09 eggplantzzz

I finally could migrate my project to ropsten. I changed to using web sockets, and set a 'networkCheckTimeout' attribute to the ropsten network in truffleconfig and it worked. Without networkCheckTimeout, the migration was not happening using either https or wss. And even with networkCheckTimeout set, the migration did not happen on https, for whatever reason that I do not understand.

That works for me too.

daoleno avatar Sep 22 '20 02:09 daoleno

@eggplantzzz I can deploy to a Truffle Teams sandbox almost every time using HDWalletProvider. I received this error the second time I tried but afterwards I got it working several times in a row. image

To be 100% on the same page: I updated my repo to use HDWalletProvider for the test network (Truffle Teams sandbox). Please pull the latest code from it. Then, I run 5 times "truffle test" on each of the networks (rinkeby, rinkeby_alchemy, test). [ rinkeby uses infura, rinkeby_alchemy uses alchemyapi and test uses TruffleTeams sandbox ]

The results:

  • "truffle test --network rinkeby" : Successfully passed all tests 1st, 2nd, 4th and 5th try. Failed 3rd try, threw this error: image

  • "truffle test --network rinkeby_alchemy" : Failed all tries. Too many requests. Threw this error: image

  • "truffle test --network test" : successfully passed all tests the 5 tries.

An interesting thing to point out is that using infura (real Rinkeby network), tests took a lot longer to execute. Using truffle sandbox, it took way less. This may have something to do.

Infura Rinkeby: image

Truffle Sandbox: image

When deploying / testing more complex contracts, it almost never goes through the whole migration.

My theory is that this has to do with how HDWalletProvider (or web3-engine-provider) deals with times out or empty blocks or similar issue.

This is so frustrating so hope you can help me with this one.

Thank you so much

jmonteer avatar Sep 22 '20 09:09 jmonteer

Thanks for the details @jmonteer! To be clear, everything works as expected unless you are using the rinkeby_alchemy network? There may be something wrong with how you are connected to their api.

Our hunch is that this is probably not a problem with HDWallet Provider. Based on the error message you posted, perhaps there is some rate-limiting going on with the Rinkeby Alchemy API?

These docs regarding configuring your networks might help? https://www.trufflesuite.com/docs/truffle/reference/configuration#networks

Please let us know if there are more details to consider or if you figure out what's going on. Thanks!

fainashalts avatar Sep 30 '20 17:09 fainashalts

Hi @fainashalts thanks for you reply.

No. The thing is that this is difficult to replicate because it is quite random. Using infura is the main problem for me. The problem is that using Infura it may successfully go through for some times in a row and then fail. This is the case with simple contract like the one I created for this demo. With more complex contracts and tests, the rate of failure is almost 100%. This is because this happens only after X transactions have been sent so if the contract deployment / test does not need many transactions to be done, it won't fail.

Regarding Alchemy API, I sent the simplecontract to the team and they said that those errors were happening because Truffle was sending too many requests (more than they believed were needed). I am using the Free Tier there but it should be enough to deploy a contract like the one I copied in this issue (simplecontract).

I am sure that my connection is working (I tried 3 different networks) and that I am correctly connecting to both Infura and Alchemy API.

I managed to deploy contracts to Rinkeby before with other projects (and versions of Truffle) but I does not seem I can get back the same npm packages.

I can add you as a contributor in one other more complex contract for you to look into this.

Thanks!

jmonteer avatar Oct 02 '20 07:10 jmonteer

Hi @jmonteer sorry for the delay in getting back to you. We haven't seen errors re: Truffle sending too many requests to Infura before. I wonder if it is possible for Alchemy API to increase its request limit. We'll see if there's anything we can do on our end, but it also is worth asking Alchemy whether there is anything they can can do here also.

fainashalts avatar Oct 14 '20 17:10 fainashalts

@jmonteer do you know whom you spoke to at Alchemy API? I'd like to reach out to them to find out more about why they think Truffle makes too many requests.

gnidan avatar Oct 14 '20 19:10 gnidan

I'm getting the same issue during ropsten deployment using infura. Seriously sucky issue. And the worst thing is, the test ether tokens are deducted from my ropsten wallet. wondering if i'd face the same issue during mainnet deployment?

C:\Users\Kombo\Code\EthFellas\codebase\node_modules\request\request.js:848
          var e = new Error('ETIMEDOUT')
                  ^
Error: PollingBlockTracker - encountered an error while attempting to update latest block:
Error: ETIMEDOUT
    at Timeout.<anonymous> (C:\Users\Kombo\Code\EthFellas\codebase\node_modules\request\request.js:848:19)
    at listOnTimeout (internal/timers.js:549:17)
    at processTimers (internal/timers.js:492:7)
    at PollingBlockTracker._performSync (C:\Users\Kombo\Code\EthFellas\codebase\node_modules\eth-block-tracker\src\polling.js:51:24)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)

i'm using : Truffle v5.1.49 (core: 5.1.49) Solidity - 0.6.10 (solc-js) Node v12.18.1 Web3.js v1.2.1

please help soon.

kombos avatar Oct 16 '20 15:10 kombos

@jmonteer do you know whom you spoke to at Alchemy API? I'd like to reach out to them to find out more about why they think Truffle makes too many requests.

Hey, I talked to Elan Harper. She's helped me so much. Since last time, alchemy api has released elastic rate limits so it may be solved by now. I'm off this week so I haven't been able to test it. I'll dm you her email.

Thanks for your help.

jmonteer avatar Oct 16 '20 15:10 jmonteer

I finally could migrate my project to ropsten. I changed to using web sockets, and set a 'networkCheckTimeout' attribute to the ropsten network in truffleconfig and it worked. Without networkCheckTimeout, the migration was not happening using either https or wss. And even with networkCheckTimeout set, the migration did not happen on https, for whatever reason that I do not understand.

I used the same parameters as mentioned and it worked for me too.

kombos avatar Oct 16 '20 16:10 kombos

Hello team @gnidan @fainashalts

I am now back from my off week. Looks like the AlchemyAPI team solved the "Too many requests error" with their new Elastic rate limits.

However, I am now getting the same ENOTFOUND error that I was getting with Infura. I am pretty sure this has something to do with how truffle (or any of its dependencies) manages empty responses.

Thanks to AlchemyAPI nice dashboard I can see that nearly 100% of the time I see the error, one of the last tx's displayed in the dashboard is like this:

image

Can I help in any other way? I am now going to try buidler and confirm this is coming from a truffle error.

Thanks for your time.

jmonteer avatar Oct 19 '20 09:10 jmonteer

I confirm that buidler deploys the contracts to Rinkeby successfully. Truffle does not, same project (~same conditions). What I said above about the null response is 99% the reason this happens.

Also, I believe that Truffle does way more requests than Buidler (but this is only my impression + I do not know what happens under the hood in each of them). Lots of calls to eth_blockNumber when running truffle migrate. .

image

hope this helps

jmonteer avatar Oct 20 '20 11:10 jmonteer

I am having a similar issue with a local custom RPC. However, I get ESOCKETTIMEDOUT for requests with eth_getBlockByNumber.

If I switch to Ropsten or Rinkeby I instead get ETIMEDOUT for requests with eth_blockNumber. Not sure if those two are related.

  • ESOCKETTIMEDOUT indicates TCP timeout.
  • ETIMEDOUT indicates HTTP timeout.

request package is deprecated, so I would recommend changing it here: https://github.com/trufflesuite/provider-engine/blob/d0a1f0a917a0c94d15778f6d5ff09470d71565f3/subproviders/rpc.js#L1.

gorgos avatar Oct 22 '20 20:10 gorgos

Hey, hello friends, I was detected to be sick in the past (🤢Yes, very unfortunate), and I have not had time to pay attention to this problem (●'◡'●). I have now returned to the United States. This morning I turned on the computer to update truffle to the latest version, and changed the Internet cable instead of connecting to the coffee shop’s wifi. This problem was solved. I don't know why this is, maybe it has something to do with the Great Firewall of China.

BlockchainsFans avatar Nov 02 '20 15:11 BlockchainsFans