Truffle test is spamming node with hundreds of eth_getBlockByNumber requests per second

[vicnaum]

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

---

Issue

Truffle sends hundreds of eth_getBlockByNumbers requests per second, and the number grows along with how long the tests go (making it closer to thousands in big test scripts). Probably that is somehow related to txReceipt, await, or smth - I'm not sure.

The result of this is node getting incredibly slow, and finally the connection crashes.

Tried with different nodes (Ganache, Hardhat, Nethermind) - the behaviour is the same.

Steps to Reproduce

1. Clone any well-known repo with large set of tests (for example xDAI stake-token: https://github.com/xdaichain/stake-token)
2. (you can skip or comment process.env lines in migrations - they load lists of tokenholders, and aren't needed for tests)
3. Run any node with logging on port 8545
4. Run truffle test
5. Wait and see how eth_getBlockByNumber requests number grows (best seen in Hardhat cause it groups similar requests)

(It was reproducible on my project too, just giving xDAI as an open-sourced example anyone can clone and reproduce)

Expected Behavior

I have no idea why truffle would need so many eth_getBlockByNumber requests for one receipt.

Actual Results

Environment

• Operating System: MacOS 10.14.5
• Ethereum client: Ganache, Hardhat, Nethermind - all latest. Web3.js v1.2.9
• Truffle version (truffle version): v5.1.52 (core: 5.1.52)
• node version (node --version): v12.19.0
• npm version (npm --version): 6.14.8

[vicnaum]

Checked different versions:

Truffle prior to 5.1.49 (including) is working fine - just one eth_getBlockByNumber per tx receipt.

But from 5.1.50 this behaviour starts and upwards to latest 5.1.53 still persists.

(Btw 5.2.0-preserves.8 works normal again - don't know what's up with this version.)

[gnidan]

There's something interacting weirdly with the version of web3 we upgraded to in 5.1.50. We're looking into the problem but don't have any leads yet. If anyone can help figure out what's causing this, it'd be much appreciated.

cc @cgewecke since I believe you brought this to our attention elsewhere

[vicnaum]

Yes, I was suspecting the web3 1.2.9 too, cause there are some issues here and there about it causing some weird behaviour (including getBlock failure).

I've tried downgrading the web3 back to 1.2.1, but the behaviour didn't change. Same with upgrading it to 1.3.0 - no positive result.

Although I did it via npm install -s web3@1.2.1 in my .npm-packages/lib/node-modules/truffle/ - so I'm not sure if that was enough - maybe worth for somebody to try that too.

[gnidan]

Truffle bundles its dependencies for portability reasons, so that won't help. Your option at this point is to downgrade to v5.1.49, unfortunately, until we can figure this out.

If we can't figure this out, Truffle might be forced to downgrade web3 itself, but I'd really like to avoid that because it took forever to upgrade in the first place :/

[cgewecke]

@gnidan @vicnaum

Root cause is discussed/diagnosed in #2688.

Idea for simple, more or less non-breaking fix in 3446 comment

[gnidan]

Workaround has been released: https://github.com/trufflesuite/truffle/releases/tag/v5.1.55

[eggplantzzz]

Closing this as a workaround has been released with version 5.1.55.

The workaround - quoting from #2688:

We didn't really think it was great to disable the confirmation listener across the board so you basically configure networks['myNetwork'].disableConfirmationListener = true in truffle-config.js to turn it off for your testing network config.

So for example in truffle-config.js:

module.exports = {
  ... // some config stuff
  networks: {
    testNetwork: {
      host: <host>,
      port: <port>,
      network_id: "*",
      disableConfirmationListener: true
    },
    ... // rest of config stuff
};

If you want it to apply to the default test network (where you won't have to run Ganache separately) then you can name it "test" and that is what Truffle will use while testing.

[kiview]

@eggplantzzz Would it be advisable to use this workaround for the default development network as well? I can't see the potential implications yet.

[drcicero]

I searched for truffle calling lots of superflous eth_getBlockByNumber and found this. I had the feeling the time the tests takes is exponential in the amount of tests that I wrote, in other words, with every new test that I write it gets worse, because later tests taking more time, because they call eth_getBlockByNumber increasingly more often.

My truffle version is

$ truffle version
Truffle v5.3.1 (core: 5.3.1)
Solidity v0.5.16 (solc-js)
Node v13.14.0
Web3.js v1.3.5

and my ganache version is

$ ganache-cli --version
Ganache CLI v6.12.2 (ganache-core: 2.13.2)

so at first I thought it cannot be this bug, because as far as I understood the linked threads it sounded like it was fixed by now. Anyway, I proceeded to use the workaround, e.g. using the above mentioned setting in truffle-config.js:

module.exports.networks.development.disableConfirmationListener = true

and it reduced the time that my truffle test takes from 12 minutes down to 3 minutes. Without the workaround the last of my testes calls eth_getBlockByNumber ca. 405 times between two transactions; with the workaround it is called precisely once per transaction. So thanks for the workaround!

[eggplantzzz]

@kiview When you send a transaction, web3 provides a listener for the "confirmation" event which I believe fires when the tx is included in a block and then again for every new block where that the transaction is part of the history. If you don't use the "confirmation" listener then I think you should be fine disabling it. The whole reason this causes slowness is because web3 polls over and over to check for these new blocks if it knows you are listening for the event.