rpc: add a rpc.rangelimit flag #33163

[gzliudan]

Proposed changes

Ref: ethereum#33163

Types of changes

What types of changes does your code introduce to XDC network?
Put an ✅ in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)
• Regular KTLO or any of the maintaince work. e.g code style
• CICD Improvement

Impacted Components

Which part of the codebase this PR will touch base on,

Put an ✅ in the boxes that apply

• Consensus
• Account
• Network
• Geth
• Smart Contract
• External components
• Not sure (Please specify below)

Checklist

Put an ✅ in the boxes once you have confirmed below actions (or provide reasons on not doing so) that

• This PR has sufficient test coverage (unit/integration test) OR I have provided reason in the PR description for not having test coverage
• Provide an end-to-end test plan in the PR description on how to manually test it on the devnet/testnet.
• Tested the backwards compatibility.
• Tested with XDC nodes running this version co-exist with those running the previous version.
• Relevant documentation has been updated as part of this PR
• N/A

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

• 🔍 Trigger a full review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[Copilot]

Pull request overview

This PR introduces a configurable maximum block-range limit for log/range queries and wires it through the filter system, RPC API, node configuration, and CLI.

Changes:

• Extends the filter system and Filter implementation to accept a RangeLimit and enforce it in Filter.Logs, with tests and benchmarks updated for the new NewRangeFilter signature.
• Adds a new RangeLimit field to ethconfig.Config, exposes it in TOML (gen_config), and introduces a new RPC CLI flag to control the maximum allowed block range.
• Propagates the range limit into the JSON-RPC filter API (GetLogs/GetFilterLogs) and the simulated backend, and registers the new flag in the XDC main CLI.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
eth/filters/filter_system.go	Adds RangeLimit to the filter system configuration so a maximum range can be configured for log filters.
eth/filters/filter.go	Extends Filter with a rangeLimit field, updates NewRangeFilter to accept it, and enforces the limit in Logs.
eth/filters/filter_test.go	Updates NewRangeFilter call sites and adds TestRangeLimit to validate that an excessive block range produces an error.
eth/filters/bench_test.go	Updates benchmarks to use the new NewRangeFilter signature while keeping range-limit disabled (0) for benchmarking.
eth/filters/api.go	Threads RangeLimit from FilterSystem into FilterAPI and passes it into NewRangeFilter for GetLogs and GetFilterLogs.
eth/ethconfig/config.go	Adds a RangeLimit field to Config with a default value of 5000 and documents its purpose.
eth/ethconfig/gen_config.go	Adds RangeLimit to the TOML marshaling/unmarshaling so it can be configured via config files.
cmd/utils/flags.go	Changes the log-query-limit flag name and introduces a new rpc-rangelimit flag, wiring it into ethconfig.Config and the filter system registration.
cmd/XDC/main.go	Registers the new rpc-rangelimit flag in the CLI’s rpcFlags, exposing the feature to node operators.
accounts/abi/bind/backends/simulated.go	Updates simulated backend FilterLogs to call the new NewRangeFilter signature with an unlimited range (0), preserving previous behaviour.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The range limit check (uint64(f.end)-uint64(f.begin)) > f.rangeLimit can underflow when f.begin > f.end, because both operands are converted to uint64 before subtraction. This yields a huge "range" and surfaces as an "exceed maximum block range" error instead of detecting an invalid block range, and also makes the computed range inconsistent with the intended end - begin semantics. Consider first validating that f.end >= f.begin (and that both are non-negative) and then computing the difference in a signed type, e.g. by checking if f.end < f.begin { return nil, errors.New("invalid block range") } followed by if uint64(f.end-f.begin) > f.rangeLimit { ... }.

Suggested change

	if f.rangeLimit != 0 && (uint64(f.end)-uint64(f.begin)) > f.rangeLimit {
	// Validate that the resolved range is non-negative and ordered correctly
	if f.begin < 0 || f.end < 0 || f.end < f.begin {
	return nil, errors.New("invalid block range")
	}
	if f.rangeLimit != 0 && uint64(f.end-f.begin) > f.rangeLimit {

[Copilot]

The new range-limit error returned here is a plain fmt.Errorf from the filters package, so when called via JSON-RPC it will be surfaced as a generic internal error rather than an invalidParamsError like other input-validation failures (e.g. errInvalidBlockRange or errExceedLogQueryLimit). For better API consistency, consider mapping range-limit violations to an invalidParamsError in the RPC layer (or defining a dedicated errExceedRangeLimit using invalidParamsErr) so clients see the standard -32602 error code instead of a generic server error.

Suggested change

	return nil, fmt.Errorf("exceed maximum block range: %d", f.rangeLimit)
	return nil, rpc.NewInvalidParamsError("exceed maximum block range: %d", f.rangeLimit)