Adds useSkipCache option to ProviderEngine constructor

[mikeshultz]

Adds a option that would allow users to disable the use of the skipCache parameter for eth_getBlockByNumber requests. This parameter is rejected by Parity and some JSON-RPC service providers like Alchemy.

// Example usage to disable the parameter
const engine = new ProviderEngine({ useSkipCache: false })

Let me know if you have any feedback. The default behavior should stay the same with this PR.

Ref: #311

[leonprou]

I tried that PR and I think I have some problem with ZeroClientProvider. I initiate the provider engine like that:

  const walletProvider = new WalletSubprovider(wallet)

  const providerEngine = new ZeroClientProvider({
    rpcUrl: CONFIG.web3.fuseProvider,
    ...walletProvider,
    engineParams: {
      useSkipCache: false
    }
  })

The ZeroClientProvider got the blockTracker. On start the blockTrackers is trying to fetch the latest block, the useSkipCache: false props sends a eth_blockNumber request without the skipCache parameter. code.

One of the providers ZeroClientProvider is composed from in BlockCacheProvider. when the eth_blockNumber request arrives to that provider it does not fetch but waits for the latest block to arrive. code. But it never sends the request.

So I just removed that cache provider from the providers list. Maybe it shouldn't be added with useSkipCache option.

[mikeshultz]

Interesting, it appears to base it's client-side cache decisions off the skipCache request property. And the block tracker does, indeed seem to wait for the latest event.

I'm not really awake yet here, so I could be missing something obvious, but I don't really see the connection between the skipCache request prop and this stalling. I suspect it might be a symptom of another issue you're having where before skipCache was causing the client to bypass this cache subprovider entirely and now it isn't.

If you have a complete test case or repro steps I'd be willing to take a look.

[leonprou]

@mikeshultz I don't think it's obvious :), just making a guess on conclusion based on my observations.

For repro steps you can see how I initialise the provider here. Then just call a send on a contract method (without specifying gas) and you should get stuck. That's what I had at least..

Then after digging into provider engine I've found out that removing the BlockCacheProvider helps with the stalling. Not sure about efficiency but it works.

[mikeshultz]

I setup this test case using ganache that's based off your initialization code and wasn't able to repro. I even included your direct call to sendAsync and everything works okay. Maybe try it with your own JSON-RPC service provider and see if you can repro. To test it:

yarn && yarn test

[mikeshultz]

gah, that test was with the main release... I can reproduce your issue. Will look into it.

[mikeshultz]

It appears to stall at the call to getLatestBlock for the block tracker which (by default) appears to sit and wait for the latest event which presumably never gets fired. That's as far as I've gotten so far, will take a look further when I get the chance.

Considering the span of repos and lack of maintainer response/interest in this PR, I'm not sure how far I want to take this, however.

[leonprou]

Yeah that's what I saw also..Well to solve this I removed the BlockCacheProvider.. So one simple solution can be to do not add it in the ZeroProvider.

I think that problem lies in the fact that the skipCache flag used both internally for providers, and also for Ethereum nodes. In my case I want to skip the BlockCacheProvider, but don't want to send the skipCache flag to Parity mode.

[kumavis]

fixed underlying issue in eth-json-rpc-middleware@4.1.5 and web3-provider-engine@15.0.2 by never sending anything but standard json rpc fields