-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Better support for Anvil/Foundry #916
Comments
I'd suggest one UX improvement on this: Anvil may be open to adding a |
Anvil doesn't need to add this, since Ponder could call the
This has stayed consistent throughout Foundry version upgrades, with "anvil/vX.X.X" being the returned response. |
Makes sense, thought a server header would be better b/c this is an additional request on startup. But makes sense |
Done in #923 |
Per discussion in the chat, Ponder doesn't currently work very well when indexing a local chain like Anvil or Hardhat Network.
Here is the proposed workflow:
a.
anvil
b.
forge script ./script/0_Deploy.s.sol:Deploy --broadcast --fork-url http://localhost:8545 ...
a.
ponder dev
a. kill
anvil
processb.
anvil
c.
forge script ./script/0_Deploy.s.sol:Deploy --broadcast --fork-url http://localhost:8545 ...
a. kill
ponder dev
processb.
ponder dev
We should be able to unblock this with some debugging and a few small changes. Here's a first pass:
networks
that disables caching. Could call itdisableCache
or maybeisLocalChain
. In practice, the easiest implementation would be to delete all cached data for that chain on startup. Ideally, this RPC cache invalidation function would be the same thing that powers the proposedponder cache
CLI entrypoint.startBlock
andendBlock
and the networklatest
andfinalized
blocks. Nearly certain we have bugs if the start block is in the unfinalized range. I'd like to design a durable solution here that also fixes [Feature] Support futureendBlock
#813.Checklist
isLocalChain
config API. Note that the ViemChain
type already hastestnet?: boolean
.startBlock
,endBlock
,latest
block number and finality block count to understand current behavior and probably find existing bugsendBlock
#813The text was updated successfully, but these errors were encountered: