refactor(jsonrpc): centralize block selector parsing into JsonRpcApiUtil#6668
Open
0xbigapple wants to merge 4 commits intotronprotocol:developfrom
Open
refactor(jsonrpc): centralize block selector parsing into JsonRpcApiUtil#66680xbigapple wants to merge 4 commits intotronprotocol:developfrom
0xbigapple wants to merge 4 commits intotronprotocol:developfrom
Conversation
bladehan1
reviewed
Apr 15, 2026
…ution, also use longValueExact in eth_getProof block number parsing and clarify the getBlockByNumOrTag comment
Collaborator
|
[NIT] A few comments in this PR use the Unicode arrow |
alan-eth
reviewed
Apr 16, 2026
Collaborator
Author
Good catch, fixed. |
…use ASCII arrows in comments, also add safe tag coverage in state-read endpoint tests
halibobo1205
assigned
bladehan1 and
waynercheung and unassigned
bladehan1 and
waynercheung
Collaborator
waynercheung
left a comment
waynercheung
left a comment
There was a problem hiding this comment.
[NIT] A few minor cleanups that can be done in a follow-up or squash:
LogFilterWrapper.java:27-28- there is still a double blank line betweentoBlockand the constructor; this should be a single blank line.LogFilterWrapperStrategyTest.java:164-filteris unused intestStrategy4_LatestGreaterThanSmallBlock_Throws; the call can be justcreateFilter(...)since the exception is expected before assignment.LogFilterWrapperStrategyTest.java:19-22,126- comments still use the Unicode arrow→whileLogFilterWrapper.javawas already switched to ASCII->; it would be better to align them for consistency.
| * Verify LogFilterWrapper strategies match develop branch behavior. | ||
| * | ||
| * Four filter strategies based on parameter emptiness (develop branch semantics): | ||
| * - Strategy 1: Both fromBlock and toBlock are empty → (currentMaxBlockNum, Long.MAX_VALUE) |
Collaborator
There was a problem hiding this comment.
replacing '→' with '->'
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 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.
What does this PR do?
This PR centralizes JSON-RPC block tag and block number resolution in
JsonRpcApiUtilso block selectors are parsed consistently across the JSON-RPC layer.It also removes
Wallet's reverse dependency on JSON-RPC code, eliminates the-1 means latestsentinel, and simplifies the block range resolution logic inLogFilterWrapper.JsonRpcApiUtil.isBlockTag,parseBlockTag, andparseBlockNumber, and moved block tag constants and related errors, includingsafe, intoJsonRpcApiUtil.TronJsonRpcImplto delegate block selector parsing toJsonRpcApiUtil;eth_getBlock*paths now use shared block resolution logic.latest-only validation for state-read APIs such asgetTrxBalance,getStorageAt,getABIOfSmartContract, andeth_call.Wallet, replaced the-1sentinel behavior, and addedgetHeadBlockNum().LogFilterWrapperby making block range handling strategy-based and easier to reason about.Why are these changes required?
Block selector parsing is currently duplicated across
Wallet,JsonRpcApiUtil, andTronJsonRpcImpl, with slightly different responsibilities and control flow in each layer.This creates several problems:
Walletcode to the JSON-RPC layer-1sentinel handling that forces callers to reinterpret results differentlyLogFilterWrapperthat is harder to maintain and verifyBy centralizing parsing in
JsonRpcApiUtil, this PR makes the behavior easier to reason about, reduces coupling, and preserves existing JSON-RPC semantics while removing fragile internal conventions.This PR has been tested by:
Follow up
None.
Extra details