eth, eth/filters: implement API error code for pruned blocks #31361
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
s1na
requested review from
fjl,
lightclient,
holiman and
rjl493456442
as code owners
s1na
commented
Mar 12, 2025
|
I have folded #31366 into this PR. Doesn't make sense to have it standalone, since changes are required in the API backend to support earliest. |
eth/api_backend.go
Outdated
| @@ -428,3 +455,8 @@ func (b *EthAPIBackend) StateAtBlock(ctx context.Context, block *types.Block, re | |||
| func (b *EthAPIBackend) StateAtTransaction(ctx context.Context, block *types.Block, txIndex int, reexec uint64) (*types.Transaction, vm.BlockContext, *state.StateDB, tracers.StateReleaseFunc, error) { | |||
| return b.eth.stateAtTransaction(ctx, block, txIndex, reexec) | |||
| } | |||
|
|
|||
| type prunedHistoryError struct{} | |||
There was a problem hiding this comment.
It's indeed weird to have duplicated error definitions in different package. Nitpick :)
There was a problem hiding this comment.
Yep agree I now made the definition in api_backend public instead.
|
Please rebase. Otherwise sgtm. Note: There may be other areas that also require cutoff handling. It's fine to merge these first |
I thought of all state-related APIs (eth_getBalance, eth_call) but I doubt archive nodes will want to prune their node. Makes me think we should probably check in the prune history command and explicitly reject it for archive nodes. |
fjl
previously approved these changes
Apr 1, 2025
… state. duplicate prunedHistoryError into eth/filters package. add HistoryCutoff method to eth backend
With history pruning, we want to redefine what the "earliest" block tag means. We need to assign a special negative integer value to this constant, otherwise we cannot tell it apart from block zero, the genesis block.
…filter on a blockhash before the prune point
fjl
approved these changes
Apr 1, 2025
fjl
changed the title
thinkAfCod
pushed a commit
to thinkAfCod/go-ethereum
that referenced
this pull request
Apr 2, 2025
…m#31361) Implements ethereum#31275 --------- Co-authored-by: Jared Wasinger <j-wasinger@hotmail.com> Co-authored-by: Felix Lange <fjl@twurst.com>
fjl
added a commit
that referenced
this pull request
Apr 3, 2025
sivaratrisrinivas
pushed a commit
to sivaratrisrinivas/go-ethereum
that referenced
this pull request
Apr 21, 2025
…m#31361) Implements ethereum#31275 --------- Co-authored-by: Jared Wasinger <j-wasinger@hotmail.com> Co-authored-by: Felix Lange <fjl@twurst.com>
sivaratrisrinivas
pushed a commit
to sivaratrisrinivas/go-ethereum
that referenced
this pull request
Apr 21, 2025
These were caused by crossed merges of recent PRs ethereum#31414 and ethereum#31361
Rampex1
pushed a commit
to streamingfast/go-ethereum
that referenced
this pull request
May 15, 2025
…m#31361) Implements ethereum#31275 --------- Co-authored-by: Jared Wasinger <j-wasinger@hotmail.com> Co-authored-by: Felix Lange <fjl@twurst.com>
Rampex1
pushed a commit
to streamingfast/go-ethereum
that referenced
this pull request
May 15, 2025
These were caused by crossed merges of recent PRs ethereum#31414 and ethereum#31361
fjl
added a commit
that referenced
this pull request
Jun 2, 2025
This changes the API backend to return null for not-found blocks. This behavior is required by the RPC When `BlockByNumberOrHash` always returned an error for this case ever since being added in #19491. The backend method has a couple of call sites, and all of them handle a `nil` block result because `BlockByNumber` returns `nil` for not-found. The only case where this makes a real difference is for `eth_getBlockReceipts`, which was changed in #31361 to actually forward the error from `BlockByNumberOrHash` to the caller.
jsvisa
pushed a commit
to jsvisa/go-ethereum
that referenced
this pull request
Jun 5, 2025
This changes the API backend to return null for not-found blocks. This behavior is required by the RPC When `BlockByNumberOrHash` always returned an error for this case ever since being added in ethereum#19491. The backend method has a couple of call sites, and all of them handle a `nil` block result because `BlockByNumber` returns `nil` for not-found. The only case where this makes a real difference is for `eth_getBlockReceipts`, which was changed in ethereum#31361 to actually forward the error from `BlockByNumberOrHash` to the caller. Signed-off-by: jsvisa <delweng@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Implements #31275
I find it a bit weird to define the error type in
eth/but I feel like that is the place to return it.