[RPC][filter] Add more block range checks

[arturgontijo]

This PR applies the same max_block_range limit (used by eth_getLogs) to all other log retrieval paths:

• eth_newFilter – Reject log filters whose block range exceeds the limit at creation.
• eth_getFilterLogs – Enforce the limit before running the query.
• eth_getFilterChanges – Enforce the limit before querying logs (Log filter branch).

The main goal is to mitigate DoS on these methods.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Walkthrough

Adds synchronous-to-async conversions for several filter-creation RPC methods and enforces a max block-range check for Log-type filters during creation, changes polling, and direct log queries; returns an error when the effective from/to span exceeds the configured maximum.

Changes

Cohort / File(s)	Summary
Filter implementation client/rpc/src/eth/filter.rs	Made create_filter async, added block-range computation/validation for Log filters in create_filter, filter_changes, and filter_logs; returns an error when effective from_block..to_block exceeds max_block_range before mutating filter state.
RPC traits client/rpc-core/src/eth.rs	Updated EthApi and EthFilterApi signatures: new_filter, new_block_filter, and new_pending_transaction_filter changed from fn to async fn (return type unchanged).
Tests ts-tests/tests/test-filter-block-range-limit.ts	Added tests asserting block-range limit behavior (MAX_BLOCK_RANGE = 10) for eth_getLogs, eth_newFilter, eth_getFilterLogs, and eth_getFilterChanges, verifying rejections for too-wide ranges and acceptance for valid ranges.

Sequence Diagram(s)

sequenceDiagram
    rect rgba(0,128,0,0.5)
    participant Client
    end
    rect rgba(0,0,128,0.5)
    participant RPC as EthFilter RPC
    end
    rect rgba(128,0,0,0.5)
    participant Chain as Chain/State
    end

    Client->>RPC: eth_newFilter / eth_getLogs / getFilterChanges
    RPC->>Chain: query best block / resolve from/to defaults
    Chain-->>RPC: current block number
    RPC->>RPC: compute effective from/to and block_range
    alt block_range <= max_block_range
        RPC->>RPC: create/store filter or fetch logs
        RPC-->>Client: success (filter id or logs)
    else block_range > max_block_range
        RPC-->>Client: error (block range exceeded)
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 28.57% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title '[RPC][filter] Add more block range checks' clearly and concisely summarizes the main change: adding block range validation checks to filter-related RPC methods.
Description check	✅ Passed	The description directly relates to the changeset, explaining how max_block_range limits are applied to eth_newFilter, eth_getFilterLogs, and eth_getFilterChanges to mitigate DoS attacks.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch artur/rpc-filter-block_range

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@client/rpc/src/eth/filter.rs`:
- Around line 387-393: The current check that rejects oversize ranges (comparing
block_range derived from current_number and from_number against
self.max_block_range) runs after last_poll has already been advanced, which can
move the cursor even on error; move the validation so it occurs before updating
last_poll (or if you prefer, roll back last_poll on error) — locate where
last_poll is updated in the polling/lock section and perform the block_range
calculation and the comparison (using current_number, from_number,
self.max_block_range) before setting last_poll, returning the internal_err if
too wide.

[librelois]

eth_newFilter range validation uses chain best block, not latest indexed block, so behavior diverges from eth_getLogs under indexing lag.
File: filter.rs (line 111)
Details: the new check in create_filter computes range with self.client.info().best_number, while eth_getLogs/other read paths cap at latest indexed. If best is ahead of indexed, eth_newFilter can reject a filter that eth_getLogs semantics would allow at that moment. This is a real behavior mismatch with the stated “same limit as eth_getLogs” goal.