Truffle: invalid request when trying migrate with parity node

Created on 18 Jul 2020 · 26Comments · Source: trufflesuite/truffle

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

i don't use twitter

Issue

trying to to a simple migration through an openethereum node

Steps to Reproduce

truffle migrate

Expected Behavior

normal migrate output

Actual Results

tcpdump output:

20:03:00.023457 IP localhost.54868 > localhost.8545: Flags [P.], seq 1:294, ack 1, win 512, options [nop,nop,TS val 2951049899 ecr 2951049898], length 293
E..Y4.@[email protected]!a#ye...$......M.....
..r...r.POST / HTTP/1.1
Content-Type: application/json
Connection: keep-alive
Host: localhost:8545
User-Agent: Mozilla/5.0 (Linux x64) node.js/10.16.0 v8/6.8.275.32-node.52
Content-Length: 80
cookie2: 
cookie: 

{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[],"skipCache":true}
20:03:00.023463 IP localhost.8545 > localhost.54868: Flags [.], ack 294, win 510, options [nop,nop,TS val 2951049899 ecr 2951049899], length 0
E..4..@.@...........!a.T..$.#yf......(.....
..r...r.
20:03:00.104063 IP localhost.8545 > localhost.54866: Flags [P.], seq 1:201, ack 294, win 512, options [nop,nop,TS val 2951049980 ecr 2951049899], length 200
E.....@.@.:/........!a.R..&Z.D.............
..r...r.HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
content-length: 77
date: Sat, 18 Jul 2020 18:03:13 GMT

{"jsonrpc":"2.0","error":{"code":-32600,"message":"Invalid request"},"id":1}

I looked in the module file, and your module and other deps are adding an option skipCache in the json-rpc, which causes calls to fail. I cannot find this option documented in the ethereum json-rpc specification.

Environment

Operating System: linux 5.7.9
Ethereum client: openethereum 3.0.0 (protocol version 64)
Truffle version (truffle version): 5.1.22
node version (node --version): 14.5.0
npm version (npm --version): 6.14.6

Source

nolash

All 26 comments

I'm seeing this as well, could be connected to https://github.com/MetaMask/web3-provider-engine/issues/311

KaiRo-at on 20 Jul 2020

https://github.com/MetaMask/web3-provider-engine/issues/311#issuecomment-522897662 says

fixed in [email protected] and [email protected]

And this is what I see with a current (truffle v5.1.23) install:

> grep "version" node_modules/@trufflesuite/web3-provider-engine/package.json 
    "type": "version",
  "version": "15.0.0-2"
> grep "version" node_modules/@trufflesuite/eth-json-rpc-middleware/package.json 
    "type": "version",
  "version": "4.4.2-1"

KaiRo-at on 20 Jul 2020

And actually, this may be pulled in by @truffle/hdwallet-provider and not by truffle itself.

KaiRo-at on 20 Jul 2020

Right, I'm actually using @truffle/hdwallet-provider @KaiRo-at

nolash on 20 Jul 2020

👍1

@CruzMolina I see you have been doing those update of the web3-provider-engine, could you integrate that upstream fix that https://github.com/MetaMask/web3-provider-engine/issues/311 talks about? Without that, us on Parity seem to be unable to deploy contracts via @truffle/hdwallet-provider :(

KaiRo-at on 20 Jul 2020

FWIW, the commandline output when you try to migrate with the bug is like this (irrelevant sections and paths shortened with placeholders):

> truffle migrate --network ropsten     

Compiling your contracts...
===========================
> Compiling [...]

> Artifacts written to /.../build/contracts
> Compiled successfully using:
   - solc: 0.6.8+commit.0bbfe453.Emscripten.clang


/.../node_modules/web3-providers-http/src/index.js:96
            callback(error, result);
            ^
Error: PollingBlockTracker - encountered an error while attempting to update latest block:
Error: Invalid request
    at /.../node_modules/@trufflesuite/web3-provider-engine/subproviders/provider.js:18:36
    at XMLHttpRequest.request.onreadystatechange (/.../node_modules/web3-providers-http/src/index.js:96:13)
    at XMLHttpRequestEventTarget.dispatchEvent (/.../node_modules/xhr2-cookies/xml-http-request-event-target.ts:44:13)
    at XMLHttpRequest._setReadyState (/.../node_modules/xhr2-cookies/xml-http-request.ts:219:8)
    at XMLHttpRequest._onHttpResponseEnd (/.../node_modules/xhr2-cookies/xml-http-request.ts:345:8)
    at IncomingMessage.<anonymous> (/.../node_modules/xhr2-cookies/xml-http-request.ts:311:39)
    at IncomingMessage.emit (events.js:327:22)
    at endReadableNT (_stream_readable.js:1221:12)
    at processTicksAndRejections (internal/process/task_queues.js:84:21)
    at PollingBlockTracker._performSync (/.../node_modules/@trufflesuite/web3-provider-engine/node_modules/eth-block-tracker/src/polling.js:51:24)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)

with those relevant lines in truffle-config.js:

const HDWalletProvider = require("@truffle/hdwallet-provider");
const mnemonic = 'my twelve words that I will not list here';

module.exports = {
  networks: {
    ropsten: {
      provider: () => new HDWalletProvider(mnemonic, 'http://localhost:8545'),
      network_id: "3"
    }
  }
}

KaiRo-at on 20 Jul 2020

Hey @KaiRo-at & @nolash , according to the most recent comments in https://github.com/MetaMask/web3-provider-engine/issues/311, it looks like this was never actually fixed??

If you can pin down a commit hash where this issue has been resolved, then I'd be happy to bump our fork of web3-provider-engine and update hdwallet-provider.

CruzMolina on 20 Jul 2020

https://github.com/MetaMask/web3-provider-engine/pull/316 seems to have fixed it for one case, but there seems to be more cases in the code.

KaiRo-at on 20 Jul 2020

That said, I can't find that PR in master though is was supposedly merged. It looks to me like the recent https://github.com/MetaMask/web3-provider-engine/commit/bd9ff60ecd0a2f2624012e8d680049ccfb6aaed2 is supposed to fix the same error as well though

KaiRo-at on 20 Jul 2020

Ah, good find @KaiRo-at , I'll take a look at updating the fork to 15.0.12.

CruzMolina on 20 Jul 2020

Hey @KaiRo-at & @nolash , can you give @truffle/hdwallet-provider@next a try?

CruzMolina on 20 Jul 2020

Hey @KaiRo-at & @nolash , can you give @truffle/hdwallet-provider@next a try?

Hrm, seems to not work for me, is the RPC subprovider even used in HDWalletProvider actually?

KaiRo-at on 21 Jul 2020

@KaiRo-at , looks like it's not.

Should RpcProvider be imported instead? (I notice it inherits ProviderSubprovider).

CruzMolina on 21 Jul 2020

Well, I'm not expert on any of that code, but given that subproviders/rpc.js does this sanitizing now, and if it inheritsProviderSubprovider, that may be a good idea - if it doesn't break stuff that worked so far, of course. ;-)

KaiRo-at on 21 Jul 2020

@KaiRo-at Pushed out another release as @truffle/hdwallet-provider@next importing RpcProvider instead. Hopefully that does the trick 🤞

CruzMolina on 21 Jul 2020

Well, the error has changed now:

/.../node_modules/request/request.js:231
    return self.emit('error', new Error('options.uri is a required argument'))
                              ^
Error: PollingBlockTracker - encountered an error while attempting to update latest block:
Error: options.uri is a required argument
    at Request.init (/.../node_modules/request/request.js:231:31)
    at new Request (/.../node_modules/request/request.js:127:8)
    at request (/.../node_modules/request/index.js:53:10)
    at RpcSource.handleRequest (/.../node_modules/@trufflesuite/web3-provider-engine/subproviders/rpc.js:25:3)
    at next (/.../node_modules/@trufflesuite/web3-provider-engine/index.js:202:18)
    at middlewareNext (/.../node_modules/@trufflesuite/web3-provider-engine/subproviders/json-rpc-engine-middleware.js:29:7)
    at SubscriptionsSubprovider.middleware (/.../node_modules/json-rpc-engine/src/createScaffoldMiddleware.js:8:14)
    at SubscriptionsSubprovider.handleRequest (/.../node_modules/@trufflesuite/web3-provider-engine/subproviders/json-rpc-engine-middleware.js:26:10)
    at next (/.../node_modules/@trufflesuite/web3-provider-engine/index.js:202:18)
    at NonceTrackerSubprovider.handleRequest (/.../node_modules/@trufflesuite/web3-provider-engine/subproviders/nonce-tracker.js:86:7)
    at next (/.../node_modules/@trufflesuite/web3-provider-engine/index.js:202:18)
    at HookedWalletSubprovider.handleRequest (/.../node_modules/@trufflesuite/web3-provider-engine/subproviders/hooked-wallet.js:311:7)
    at next (/.../node_modules/@trufflesuite/web3-provider-engine/index.js:202:18)
    at Web3ProviderEngine._handleAsync (/.../node_modules/@trufflesuite/web3-provider-engine/index.js:189:3)
    at /.../node_modules/eth-block-tracker/src/polling.js:71:51
    at /.../node_modules/eth-block-tracker/node_modules/pify/index.js:49:6
    at new Promise (<anonymous>)
    [...]

Looking at the fact that rpc.js does the actual HTTP request as well, I also somewhat wonder if that will break non-http providers, e.g.. ws ones...

KaiRo-at on 21 Jul 2020

Ah, thanks for the stack trace @KaiRo-at! I just published another prerelease as @truffle/hdwallet-provider@next with a fix for the missing uri and made sure to only use RpcProvider for HTTP providers/requests. 🤞

CruzMolina on 21 Jul 2020

👍1

Now that looks pretty good! My test deployment to Ropsten now fails with Insufficient funds, which is expected with an empty deploy account, but it means we don't see the error any more that this issue is about! o/

That said, anyone using Parity/OpenEthereum with a ws provider will still fail, but that's a way smaller group :)

KaiRo-at on 21 Jul 2020

That said, anyone using Parity/OpenEthereum with a ws provider will still fail, but that's a way smaller group :)

I'm guessing the natural extension here is to import WebsocketProvider and use that when a ws provider is detected...

CruzMolina on 21 Jul 2020

@KaiRo-at , published to @next again, implementing WebsocketProvider when a websocket provider is detected. Seems to work on my end so far 🤞

CruzMolina on 21 Jul 2020

@CruzMolina I got it working, too. How can I verify which version of the @truffle/hdwallet-provider I used though?

nolash on 21 Jul 2020

@nolash check your package.json and package-lock.json

CruzMolina on 21 Jul 2020

@nolash if you can share the version you're using, then I can move forward with making these changes official.

CruzMolina on 21 Jul 2020

@CruzMolina here's my package-lock.json:

https://swarm-gateways.net/bzz:/e5339d1067137dd682fe88290ab552e9d7fed4c9ca11c0587037ce92478600e7/

nolash on 22 Jul 2020

Thanks @nolash ! That's the latest release tagged as next. Will move forward with trying to make these changes official.

CruzMolina on 22 Jul 2020

👍1

FWIW - I also still had this problem & ended up leaving the parity node for geth , now works. but there is def still some open issue about it

fxfactorial on 11 Sep 2020

Was this page helpful?

0 / 5 - 0 ratings

Related issues

Truffle cannot migration with the latest Geth 1.8

hickscorp · 53Comments

Deployed Contracts have no Network when using async/await

jleeh · 29Comments

Unable to deploy to live network - "Contract transaction couldn't be found after 50 blocks"

nonsenseless · 32Comments

Truffle develop timeout error

KadenZipfel · 31Comments

Error: Invalid number of arguments to Solidity function in tests after upgrading to 4.0.0

dwalintukan · 47Comments