-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
feat: getLogs
cheatcode
#5297
feat: getLogs
cheatcode
#5297
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for this! it's going in the right direction. let's keep resolving the TODOs left, and:
- making the test data a fixture
- removing the unneeded comments once todos are solved
- extract the cheatcode itself into a function.
also, left a nit re: formatting.
testdata/cheats/Fork2.t.sol
Outdated
} | ||
|
||
/* The response from the above eth_call | ||
// TODO put into a fixture |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sweet yes! i'd also include some comments on how to regen this fixture, if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Included in README.md
under testdata/fixtures/Rpc
folder.
return Some(Ok(empty)); | ||
*/ | ||
|
||
let logs = RuntimeOrHandle::new().block_on(provider.get_logs(&filter)).unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @mattsse — ig there's no way to avoid spawning a blocking handle here right?
This PR basically adds a new The ability to call RPC methods from tests/scripts has been a request for a long time, often to allow configuring anvil into a specified state from a forge script. So before merging a one-off cheat for this method I think it's worth framing this more broadly around "how to call RPC methods from script/tests". I see three options:
I lean towards 2 or 3, and also lean towards just matching the full RPC method name for clarity. Interested to hear other thoughts on this |
I also strongly support matching the full RPC method name, that's a great suggestion. We can also name the return type as Between approaches 2 and 3, I lean towards 3 because I think there are strong benefits for type-safety for the most common RPC calls, but the |
Great, I'm on board with all of this, as long as @mattsse / @Evalir also agree. Then the one nit we'll have to standardize is the naming conventions:
My weakly held opinion here is |
If we're all on board with the following, can start working on implementing this!
|
I'm onboard with the naming—while i think |
whoops @puma314 sorry—marked this as RFR even though youre still cleaning up. Feel free to ping me when you want another review round! |
@Evalir ready for another round of review! Addressed all of your existing comments for |
Sweet! Do you think you can resolve the conflicts? @puma314 |
Just fixed @Evalir! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking good! just some more asks re docs and tests.
would love your eyes here @mattsse!
8e9e768
to
e8b3a79
Compare
4c29fd8
to
7f4d16b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aight, took this over the line—just needed a smol fix to the test. Thank you!
Thank you so much @Evalir!! Sorry the last few weeks got a little busy so I didn't have time to finish this up. Awesome that this is finally merged in, I'm excited to use it :D |
* Initial implementation * More comprehensive test * Added TODOs * Test passes * Cleaning up PR * Tests pass * Cleaned up get_logs, starting to work on rpc * eth get logs should be done. still working on rpc * RPC test works with get_balance * Formatting * Removed pub * Minor solidity fixes * Remake public * Cheats -> vm * chore: docs * chore: docs * chore: clippy * fmt * chore: fix path * chore: enable permissions * enable permissions --------- Co-authored-by: Enrique Ortiz <[email protected]>
Motivation
Right now there is a
getRecordedLogs()
cheatcode that allows users to callvm.recordLogs()
and retrieve subsequent emitted logs for post-processing or other use-cases.However, there is no way for users to retrieve logs that are emitted outside of the
recordLogs()
context.A lot developers use one-off Typescript and Go scripts to retrieve logs and then conditionally call other Solidity functions with them. This requires significant duplication of existing Solidity logic in other languages. If these scripts could be replaced with Forge scripts that are able to interact with existing Solidity logic, it would simplify off-chain workflows significantly. The ability to retrieve logs in a similar manner to the
getLogs
RPC within a Forge script is the main blocker to using Forge scripts for these sorts of tasks.Solution
Create a new cheatcode
getLogs(uint256 fromBlock, uint256 toBlock, address filterAddress, bytes32[] memory topics)
with the same arguments as theeth_getLogs
RPC.If there is an active fork, use the
fork_url
to query thegetLogs
RPC and return the result as avm.Logs[]
object. If there is no active fork, then throw an error.