Truffle: Any contract or library named "Buffer" prevents truffle console from connecting to testnets (on Node.js 12+ only)

Created on 20 Mar 2020  路  3Comments  路  Source: trufflesuite/truffle

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

Issue

When using @truffle/hdwallet-provider configured for a testnet, truffle console will fail to connect if there exists a compiled contract or library with the exact name "Buffer".

Steps to Reproduce

I have created a simple repo that reproduces the issue: https://github.com/coffee-converter/truffle-console-buffer-error

Or, set up your own project:

  • Use Node.js version 12 or higher.
  • Install truffle 5.1.18 and `@truffle/hdwallet-provider 1.0.33.
  • Configure a testnet network in truffle-config.js.
  • Create a contract or library named "Buffer". It can be totally empty: contract Buffer {}
  • Compile with truffle compile.
  • Try truffle console --network rinkeby or whatever testnet you configured.

Expected Behavior

The console should start normally and connect without errors.

Actual Results

The console does not properly connect, and errors are displayed:

Error: CONNECTION ERROR: Couldn't connect to node https://rinkeby.infura.io/v3/**************************.
    at Object.InvalidConnection (\node_modules\web3-core-helpers\src\errors.js:35:16)
    at HttpProvider.send (\node_modules\web3-providers-http\src\index.js:109:25)
    at ProviderSubprovider.handleRequest (\node_modules\web3-provider-engine\subproviders\provider.js:16:17)
    at next (\node_modules\web3-provider-engine\index.js:119:18)
    at FilterSubprovider.handleRequest (\node_modules\web3-provider-engine\subproviders\filters.js:89:7)
    at next (\node_modules\web3-provider-engine\index.js:119:18)
    at NonceTrackerSubprovider.handleRequest (\node_modules\web3-provider-engine\subproviders\nonce-tracker.js:79:7)
    at next (\node_modules\web3-provider-engine\index.js:119:18)
    at HookedWalletSubprovider.handleRequest (\node_modules\web3-provider-engine\subproviders\hooked-wallet.js:234:7)
    at next (\node_modules\web3-provider-engine\index.js:119:18)
    at Web3ProviderEngine._handleAsync (\node_modules\web3-provider-engine\index.js:106:3)
    at EthQuery.sendAsync (\node_modules\eth-query\index.js:66:24)
    at EthQuery.getBlockByNumber (\node_modules\eth-query\index.js:80:10)
    at \node_modules\pify\index.js:29:7
    at new Promise (<anonymous>)
    at EthQuery.<anonymous> (\node_modules\pify\index.js:12:10)
    at EthQuery.ret (\node_modules\pify\index.js:56:34)
    at RpcBlockTracker._fetchBlockByNumber (\node_modules\eth-block-tracker\src\index.js:200:47)
    at RpcBlockTracker._performSync (\node_modules\eth-block-tracker\src\index.js:120:35)
    at Timeout._onTimeout (\node_modules\eth-block-tracker\src\index.js:110:27)
    at listOnTimeout (internal/timers.js:549:17)
    at processTimers (internal/timers.js:492:7)

Environment

  • Operating System: Windows 10 or Ubuntu 18.04
  • Ethereum client: @truffle/hdwallet-provider configured for an Infura node
  • Truffle version (truffle version): 5.1.18
  • node version (node --version): 12.0.0 and higher
  • npm version (npm --version): 6.9.0 and higher
bug needs requirements priority3 馃敡

All 3 comments

What a strange find, it also hangs for me on Node 10. Thanks for the report!

Incidentally it is not necessarily all test nets. When I run truffle develop it also hangs without providing me with a prompt.

What a funny problem! So this seems to happen in the console because the console uses Node.js's built-in Buffer, and then Truffle goes and clobbers that name with your contract. So no Node buffer; the console is trying to stream bytes to your contract abstraction, which of course does not have any notion that it should handle that :)

Not sure about workaround. There might be a way to detect this sort of name collision and make a backup namespace (so you'd do something like contracts.Buffer in the console, as a workaround). Calling this "needs requirements"

(I hear this is @eggplantzzz's favorite issue :)

Closing this in favor of #3329 which is a bit more general.

Was this page helpful?
0 / 5 - 0 ratings