Skip to content
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

eth_newFilter RPC incompatibility - fromBlock and toBlock should default to "latest" #1194

Closed
jaeaster opened this issue Dec 3, 2022 · 2 comments

Comments

@jaeaster
Copy link

jaeaster commented Dec 3, 2022

When we stream events from an event filter, ethers-rs omits fromBlock and toBlock ... those are optional args and seems like FVM implicitly requires those args, otherwise we do not receive any events when we should. They should both default to "latest" as per infura docs.

https://docs.infura.io/infura/networks/ethereum/json-rpc-methods/filter-methods/eth_newfilter

I wasn't able to verify the actual behavior from a quick glance through the code. Perhaps those args are defaulting to "latest", but the subsequent behavior is different.

What I expect to happen is when I install a filter, I can query that filter over time and receive any logs matching the filter from the block when the filter is installed until I stop querying the filter or it's uninstalled, etc.

Here's an example snippet of code using ethers-rs (the stream() method omits fromBlock and toBlock).

        let events = self.contract.new_dkg_created_filter();
        let mut stream = events.stream().await?;

This code works with other RPCs, but never receives future events on Wallaby. However, when I add fromBlock = 'latest' and toBlock = 'latest' explicitly, I do receive the events I expect.

@jaeaster
Copy link
Author

jaeaster commented Dec 5, 2022

Looked closer at the code, fromBlock and toBlock default to "latest" as expected, so this doesn't seem to be the root of my issue. Will update with more details once I figure it out.

@jaeaster
Copy link
Author

jaeaster commented Dec 6, 2022

Yes - I was mistaken. I made a different issue to describe the actual problem I experienced
#1207

Closing this issue as it's irrelevant

@jaeaster jaeaster closed this as completed Dec 6, 2022
@maciejwitowski maciejwitowski added this to the M2.1 (rr10) Carbonado milestone Dec 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants