Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Handle Infura archive error #29

Open
v-stickykeys opened this issue Jun 15, 2021 · 1 comment
Open

Handle Infura archive error #29

v-stickykeys opened this issue Jun 15, 2021 · 1 comment

Comments

@v-stickykeys
Copy link
Member

v-stickykeys commented Jun 15, 2021

Problem

When using the default Infura mainnet endpoint, you get the latest 128 blocks of Ethereum state. Given a block production rate of about 13 seconds, that is about 27 minutes of full mainnet state. This means when you run ganache and fork off of mainnet you will get an error when trying to retrieve block state created 27 minutes prior to when you started.

As an example,

  • Alex is running ganache-cli with the -f flag set to an Infura mainnet websocket url
  • Alex runs tests against ganache-cli deploying a contract in block 1
  • 13 seconds later the block height is 2
  • 30 minutes later the block height is 138
  • When Alex attempts to run a test accessing the full state from block 1 an error to the tune of project ID does not have access to archive state will be thrown by Infura

Based on the Infura docs on archive data:

Because of the way account and contract storage works in Ethereum, this means that only an archive node can serve API request for certain RPC methods older than 128 blocks.

Solutions

So far I see 2 ways to handle this:

  1. Keep your testing within 128 blocks (and restart ganache-cli after 128 blocks so you don't accidentally exceed this when testing)
  2. Spin up another ganache with shared state before the first expires and switch to it (basically, keep the state around in ganache that would otherwise get pruned and make the request for state use this cache instead of making the json rpc request to infura)
  3. Require users to design tests such that they don't retrieve state after 128 blocks (not sure that this would exactly solve it, probably more nuance here)

Proposal

I propose we start with solution 1 and explore 2 in the future because it is very reasonable for testing to exceed 27 minutes

@v-stickykeys
Copy link
Member Author

To flesh this out a bit more, what we want is:

  • Alex uses a url for godmode ganache
  • Alex awaits godmode ganache starting at the top of a test suite
  • The tests run
  • If an error occurs in the tests, a request is made to shut down godmode ganache before the process exits
  • If the tests finish without error, a request is made to shut down godmode ganache before the process exits

This requires a few components:

  1. API endpoints to start and stop godmode ganache running
  2. An interface in the godmode library (or elsewhere?) to allow users to make requests to the endpoint above
  3. Documentation and examples on the proper start up/clean up usage and docs on how to handle the archive error (or do we watch for the archive error and reset for them? then include a response message that says state was reset?)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant