eth/filters, cmd: add config of eth_getLogs address limit #33320 #32327#1961
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the
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. Comment |
62d7470 to
89a2f90
Compare
89a2f90 to
138bfeb
Compare
138bfeb to
bf63562
Compare
bf63562 to
9439af8
Compare
There was a problem hiding this comment.
Pull request overview
Adds a configurable cap for eth_getLogs (and log subscriptions) to limit the number of addresses/topic-alternatives accepted in filter criteria, exposed via node config and CLI.
Changes:
- Introduce
LogQueryLimitin the filters system and ETH config, with TOML + CLI wiring. - Enforce the limit in
eth_getLogsand log subscriptions, updating error handling and tests accordingly. - Update tests to validate the new limit behavior and remove legacy hard-coded max-address unmarshalling coverage.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| eth/filters/filter_system.go | Adds LogQueryLimit to filter system config and applies it in SubscribeLogs. |
| eth/filters/api.go | Adds API-level enforcement for LogQueryLimit in GetLogs and updates error types. |
| eth/filters/filter_system_test.go | Updates filter system tests to use the configured limit instead of a fixed constant. |
| eth/filters/api_test.go | Removes legacy test that depended on the old hard-coded max-address limit during JSON unmarshal. |
| eth/ethconfig/config.go | Adds LogQueryLimit to ETH config defaults and struct documentation. |
| eth/ethconfig/gen_config.go | Extends TOML marshal/unmarshal support for the new config field. |
| cmd/utils/flags.go | Adds CLI flag + config plumbing for LogQueryLimit and passes it into filter system config (in this helper). |
| cmd/XDC/main.go | Registers the new CLI flag in the XDC command. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if api.logQueryLimit != 0 { | ||
| if len(crit.Addresses) > api.logQueryLimit { | ||
| return nil, errExceedLogQueryLimit | ||
| } | ||
| for _, topics := range crit.Topics { |
There was a problem hiding this comment.
Same as in SubscribeLogs: using api.logQueryLimit != 0 means negative values would reject even empty addresses/topics. Treat only positive values as an active cap (e.g., > 0) or validate the config before constructing the API.
| errExceedMaxTopics = errors.New("exceed max topics") | ||
| errExceedLogQueryLimit = errors.New("exceed max addresses or topics per search position") |
There was a problem hiding this comment.
errInvalidTopic/errInvalidBlockRange/errBlockHashWithRange now return JSON-RPC “invalid params” (-32602) via invalidParamsError, but errExceedMaxTopics / errExceedLogQueryLimit are still plain errors.New and will be reported with the default RPC error code. These are also invalid-params cases; consider defining them via invalidParamsErr(...) for consistent JSON-RPC error codes.
| errExceedMaxTopics = errors.New("exceed max topics") | |
| errExceedLogQueryLimit = errors.New("exceed max addresses or topics per search position") | |
| errExceedMaxTopics = invalidParamsErr("exceed max topics") | |
| errExceedLogQueryLimit = invalidParamsErr("exceed max addresses or topics per search position") |
| RPCGlobalLogQueryLimit = &cli.IntFlag{ | ||
| Name: "rpc.logquerylimit", | ||
| Usage: "Maximum number of alternative addresses or topics allowed per search position in eth_getLogs filter criteria (0 = no cap)", | ||
| Value: ethconfig.Defaults.LogQueryLimit, | ||
| Category: flags.APICategory, | ||
| } |
There was a problem hiding this comment.
Flag naming is inconsistent with the established pattern in this file where the primary name uses dashes and the dot-form is provided as an alias (e.g. cache-blocklogs/cache.blocklogs, rpc-txfeecap/rpc.txfeecap). Consider renaming the primary flag to rpc-logquerylimit and adding rpc.logquerylimit as an alias to match existing conventions.
| filterSystem := filters.NewFilterSystem(backend, filters.Config{ | ||
| LogCacheSize: ethcfg.FilterLogCacheSize, | ||
| LogCacheSize: ethcfg.FilterLogCacheSize, | ||
| LogQueryLimit: ethcfg.LogQueryLimit, | ||
| }) |
There was a problem hiding this comment.
This wires ethcfg.LogQueryLimit into the filter system created here, but there are other filters.NewFilterSystem call sites that still don’t pass the new field (e.g. eth/backend.go:429). If those code paths are used to expose the eth filter APIs, the new rpc.logquerylimit/TOML setting won’t have any effect. Consider updating all production call sites to propagate LogQueryLimit (or centralizing FilterSystem creation).
| Timeout time.Duration // how long filters stay active (default: 5min) | ||
| LogCacheSize int // maximum number of cached blocks (default: 32) | ||
| Timeout time.Duration // how long filters stay active (default: 5min) | ||
| LogQueryLimit int // maximum number of addresses allowed in filter criteria (default: 1000) |
There was a problem hiding this comment.
LogQueryLimit’s comment is inaccurate: the limit is enforced for both the number of addresses and the number of topic alternatives per topic-position, and 0 is treated as “no cap” by the callers. Please update the field comment to match the actual semantics (and avoid claiming a default of 1000 here unless withDefaults enforces it).
| LogQueryLimit int // maximum number of addresses allowed in filter criteria (default: 1000) | |
| LogQueryLimit int // maximum number of addresses and topic alternatives per position allowed in log filter criteria; 0 means no limit |
| if es.sys.cfg.LogQueryLimit != 0 { | ||
| if len(crit.Addresses) > es.sys.cfg.LogQueryLimit { | ||
| return nil, errExceedLogQueryLimit | ||
| } | ||
| for _, topics := range crit.Topics { |
There was a problem hiding this comment.
The limit guard uses LogQueryLimit != 0. If a user misconfigures this to a negative number (possible via TOML/CLI), len(...) > LogQueryLimit will be true even for empty slices, effectively breaking log subscriptions. Consider treating only positive values as an active cap (e.g., > 0) and/or validating the config on startup.
Proposed changes
Ref: ethereum#32327
Types of changes
What types of changes does your code introduce to XDC network?
Put an
✅in the boxes that applyImpacted Components
Which part of the codebase this PR will touch base on,
Put an
✅in the boxes that applyChecklist
Put an
✅in the boxes once you have confirmed below actions (or provide reasons on not doing so) that