[WIP] eth/filters: remove support for pending logs #28623 #29574 #2015
+103
−637
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gzliudan
requested review from
AnilChinchawale,
anunay-xin,
benjamin202410,
Copilot,
liam-lai and
wanwiset25
|
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 |
There was a problem hiding this comment.
Pull request overview
This PR removes support for pending logs subscriptions from the Ethereum filters system. The functionality was deemed unreliable since nodes must speculatively execute mempool transactions to generate pending logs, which can never be fully accurate. The PR simplifies the filter system by removing the pending logs feature and the light mode parameter.
Changes:
- Removed
PendingBlockAndReceipts()andSubscribePendingLogsEvent()from the filters Backend interface - Removed
lightModeparameter fromNewEventSystem()andNewFilterAPI()functions - Added
errPendingLogsUnsupportederror for pending logs queries - Removed pending logs subscription types (
PendingLogsSubscription,MinedAndPendingLogsSubscription) - Removed light client-specific filtering logic
- Updated all tests to reflect the removal of pending logs functionality
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| eth/filters/api.go | Added new error for unsupported pending logs, removed lightMode parameter from NewFilterAPI |
| eth/filters/filter.go | Removed pendingLogs() method, simplified block range validation to reject pending block numbers |
| eth/filters/filter_system.go | Removed pending logs subscription types, event handling, light mode filtering logic, and associated helper methods |
| eth/filters/filter_test.go | Updated tests to expect errors for pending log queries instead of returning results |
| eth/filters/filter_system_test.go | Removed TestPendingLogsSubscription and TestLightFilterLogs tests, updated test setup to remove lightMode parameter |
| eth/backend.go | Updated NewFilterAPI call to remove lightMode parameter |
| cmd/utils/flags.go | Updated NewFilterAPI call to remove lightMode parameter |
| accounts/abi/bind/backends/simulated.go | Updated NewEventSystem calls to remove lightMode parameter |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@eth/filters/filter.go`:
- Around line 147-169: Add an explicit validation in the filter range
resolution: after calling resolveSpecial for f.begin and f.end (before assigning
f.begin/f.end and before any arithmetic or rangeLimit checks in the function
that calls rangeLogsAsync), check if end < begin and return a clear
invalid-range error (consistent with SubscribeLogs) instead of proceeding;
update the code paths around resolveSpecial, the rangeLimit check, and the call
sites (e.g., where f.begin/f.end are set and rangeLogsAsync is invoked) to
ensure the new validation prevents silent empty results and underflowed
subtraction when computing (end - begin).
Comment on lines
147
to
+169
| // range query need to resolve the special begin/end block number | ||
| if f.begin, err = resolveSpecial(f.begin); err != nil { | ||
| begin, err := resolveSpecial(f.begin) | ||
| if err != nil { | ||
| return nil, err | ||
| } | ||
| if f.end, err = resolveSpecial(f.end); err != nil { | ||
| end, err := resolveSpecial(f.end) | ||
| if err != nil { | ||
| return nil, err | ||
| } | ||
| if f.rangeLimit != 0 && (uint64(f.end)-uint64(f.begin)) > f.rangeLimit { | ||
| if f.rangeLimit != 0 && (end-begin) > f.rangeLimit { | ||
| return nil, fmt.Errorf("exceed maximum block range: %d", f.rangeLimit) | ||
| } | ||
|
|
||
| f.begin = int64(begin) | ||
| f.end = int64(end) | ||
| logChan, errChan := f.rangeLogsAsync(ctx) | ||
| var logs []*types.Log | ||
| for { | ||
| select { | ||
| case log := <-logChan: | ||
| logs = append(logs, log) | ||
| case err := <-errChan: | ||
| if err != nil { | ||
| // if an error occurs during extraction, we do return the extracted data | ||
| return logs, err | ||
| } | ||
| // Append the pending ones | ||
| if endPending { | ||
| pendingLogs := f.pendingLogs() | ||
| logs = append(logs, pendingLogs...) | ||
| } | ||
| return logs, nil | ||
| return logs, err |
There was a problem hiding this comment.
Add explicit end ≥ begin validation before range arithmetic.
Right now, if end < begin and rangeLimit == 0, the filter silently returns empty results; when rangeLimit != 0, (end-begin) underflows and yields a misleading “exceed maximum block range” error. Consider returning an invalid-range error up front (consistent with SubscribeLogs).
💡 Suggested fix
end, err := resolveSpecial(f.end)
if err != nil {
return nil, err
}
+ if end < begin {
+ return nil, errInvalidBlockRange
+ }
if f.rangeLimit != 0 && (end-begin) > f.rangeLimit {
return nil, fmt.Errorf("exceed maximum block range: %d", f.rangeLimit)
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| // range query need to resolve the special begin/end block number | |
| if f.begin, err = resolveSpecial(f.begin); err != nil { | |
| begin, err := resolveSpecial(f.begin) | |
| if err != nil { | |
| return nil, err | |
| } | |
| if f.end, err = resolveSpecial(f.end); err != nil { | |
| end, err := resolveSpecial(f.end) | |
| if err != nil { | |
| return nil, err | |
| } | |
| if f.rangeLimit != 0 && (uint64(f.end)-uint64(f.begin)) > f.rangeLimit { | |
| if f.rangeLimit != 0 && (end-begin) > f.rangeLimit { | |
| return nil, fmt.Errorf("exceed maximum block range: %d", f.rangeLimit) | |
| } | |
| f.begin = int64(begin) | |
| f.end = int64(end) | |
| logChan, errChan := f.rangeLogsAsync(ctx) | |
| var logs []*types.Log | |
| for { | |
| select { | |
| case log := <-logChan: | |
| logs = append(logs, log) | |
| case err := <-errChan: | |
| if err != nil { | |
| // if an error occurs during extraction, we do return the extracted data | |
| return logs, err | |
| } | |
| // Append the pending ones | |
| if endPending { | |
| pendingLogs := f.pendingLogs() | |
| logs = append(logs, pendingLogs...) | |
| } | |
| return logs, nil | |
| return logs, err | |
| // range query need to resolve the special begin/end block number | |
| begin, err := resolveSpecial(f.begin) | |
| if err != nil { | |
| return nil, err | |
| } | |
| end, err := resolveSpecial(f.end) | |
| if err != nil { | |
| return nil, err | |
| } | |
| if end < begin { | |
| return nil, errInvalidBlockRange | |
| } | |
| if f.rangeLimit != 0 && (end-begin) > f.rangeLimit { | |
| return nil, fmt.Errorf("exceed maximum block range: %d", f.rangeLimit) | |
| } | |
| f.begin = int64(begin) | |
| f.end = int64(end) | |
| logChan, errChan := f.rangeLogsAsync(ctx) | |
| var logs []*types.Log | |
| for { | |
| select { | |
| case log := <-logChan: | |
| logs = append(logs, log) | |
| case err := <-errChan: | |
| return logs, err |
🤖 Prompt for AI Agents
In `@eth/filters/filter.go` around lines 147 - 169, Add an explicit validation in
the filter range resolution: after calling resolveSpecial for f.begin and f.end
(before assigning f.begin/f.end and before any arithmetic or rangeLimit checks
in the function that calls rangeLogsAsync), check if end < begin and return a
clear invalid-range error (consistent with SubscribeLogs) instead of proceeding;
update the code paths around resolveSpecial, the rangeLimit check, and the call
sites (e.g., where f.begin/f.end are set and rangeLogsAsync is invoked) to
ensure the new validation prevents silent empty results and underflowed
subtraction when computing (end - begin).
This change removes support for subscribing to pending logs. "Pending logs" were always an odd feature, because it can never be fully reliable. When support for it was added many years ago, the intention was for this to be used by wallet apps to show the 'potential future token balance' of accounts, i.e. as a way of notifying the user of incoming transfers before they were mined. In order to generate the pending logs, the node must pick a subset of all public mempool transactions, execute them in the EVM, and then dispatch the resulting logs to API consumers.
gzliudan
force-pushed
the
disable-pending-logs
branch
from
ca41258 to
96816b2
Compare
benjamin202410
approved these changes
Feb 5, 2026
anunay-xin
approved these changes
Feb 5, 2026
gzliudan
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change removes support for subscribing to pending logs.
"Pending logs" were always an odd feature, because it can never be fully reliable. When support for it was added many years ago, the intention was for this to be used by wallet apps to show the 'potential future token balance' of accounts, i.e. as a way of notifying the user of incoming transfers before they were mined. In order to generate the pending logs, the node must pick a subset of all public mempool transactions, execute them in the EVM, and then dispatch the resulting logs to API consumers.
Ref:
Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.
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) thatSummary by CodeRabbit
Release Notes
✏️ Tip: You can customize this high-level summary in your review settings.