Add test coverage for filter-related Ethereum API methods

[elmattic]

Summary

Here’s a list of currently untested filter-related methods in Forest:

• eth_newFilter / eth_uninstallFilter
• eth_newBlockFilter
• eth_newPendingTransactionFilter
• eth_getFilterChanges
• eth_getFilterLogs

We should add comprehensive integration tests that cover all meaningful scenarios.

The existing API comparison tests are not designed to check interactions or combinations of these methods. Therefore, we need to write dedicated scripts for each endpoint and, where relevant, for endpoint pairs.

Below are some proposals (not exhaustive) on how to approach this testing effort:

eth_newFilter

Currently, we only test the method by varying the address parameter while keeping other parameters at their defaults.
We should instead cover all possible EthFilterSpec variations (assuming there are already unit tests for EthFilterSpec itself).

To prevent abuse (e.g., clients creating millions of filters), Forest should enforce a practical or configurable limit.
If this limit already exists, it should also be tested via the API.

eth_uninstallFilter

At present, we only test uninstalling a default, freshly created filter, effectively testing for failure.

We should test correct usage, for example:

• Install filter A -> uninstall filter A
• Install filters A and B -> uninstall filters A and B

We should also test edge cases, like attempting to uninstall an already uninstalled filter.

eth_newBlockFilter

This is mostly untested.
We should test the eth_newBlockFilter / eth_getFilterChanges pair and ensure the results conform to the specification.

eth_newPendingTransactionFilter

Also largely untested.
We should test the eth_newPendingTransactionFilter / eth_getFilterChanges pair and verify correctness according to the spec.

This will likely require sending one or more transactions (eth_sendTransaction) to our node.

eth_getFilterLogs

Mostly untested.
We should test the eth_newFilter / eth_getFilterLogs pair and confirm correctness as specified.

This likely involves interacting with a smart contract to generate logs that we can retrieve (e.g. some simple
erc20 contract).

Additionally, we should:

• Test behavior with many concurrently installed filters (e.g., around 100) and measure performance, ensuring it remains reasonable and comparable to Lotus.
• Verify the configured maximum limit (FOREST_MAX_FILTER_RESULTS).

eth_getFilterChanges

Currently affected by eth_newFilter and not properly tested.
This method depends heavily on polling and internal state (last pool).
We should test:

• Regular polling scenarios
• Filter expiration after the typical timeout (~5 minutes without polling), after which eth_getFilterChanges should return “filter not found.”

✅ Note

All these scripts should ideally be written to also work against Lotus, the reference implementation.
This way, we can first validate correctness on Lotus, then run them against Forest to ensure compatibility.

Completion Criteria

All integration tests and unit tests (if necessary) are passing.

Additional Links & Resources

https://docs.filecoin.io/reference/json-rpc/eth