-
Notifications
You must be signed in to change notification settings - Fork 839
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPC methods that lookup block by hash will now return error if no block found #4582
Conversation
Signed-off-by: Sally MacFarlane <macfarla.github@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Signed-off-by: Sally MacFarlane <macfarla.github@gmail.com>
Signed-off-by: Sally MacFarlane <macfarla.github@gmail.com>
Signed-off-by: Sally MacFarlane <macfarla.github@gmail.com>
Signed-off-by: Sally MacFarlane <macfarla.github@gmail.com>
Signed-off-by: Sally MacFarlane <macfarla.github@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I argue this (and geth) are out of spec
https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbyhash
Returns
Object - A block object, or null when no block was found: [... description of fields ...]
Furthermore this touches on endpoints that use the "default block parameter." Querying by Hash is not a valid option. The data type is "BlockNumberOrTag" - https://github.com/ethereum/execution-apis/blob/main/src/eth/state.yaml#L60 And the type does not accept hashes - https://github.com/ethereum/execution-apis/blob/main/src/schemas/block.yaml#L92-L108 So if there was movement towards the spec conformance direction that step would be to not return answers when looking up by hash even when one is found. |
...src/main/java/org/hyperledger/besu/ethereum/api/jsonrpc/internal/methods/DebugAccountAt.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Agree this does not match the spec. This change was made here #1784 |
There has been further conversation here https://discord.com/channels/595666850260713488/595701319793377299/1041758135821533266 indicating that it should be part of the spec. EIP-1898 - changing status from stagnant to draft ethereum/EIPs#5980 and adding relevant parts to the spec ethereum/execution-apis#326 |
Update on this
|
This execution APIs spec has been updated per ethereum/execution-apis#326 so bumping this for review |
This execution APIs spec has been updated per ethereum/execution-apis#326 to allow block hash
Signed-off-by: Sally MacFarlane <macfarla.github@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The official execution spec is disturbingly void of standard error handing. I'll approve this on the presumption that this is not at odds with how other clients handle such an exception.
Thanks @shemnon - this PR actually arose out of an effort to standardise error handling across clients ethereum/execution-apis#286 |
…ck found (hyperledger#4582) * add specific error for block by hash lookup not found Signed-off-by: Sally MacFarlane <macfarla.github@gmail.com> Signed-off-by: Sally MacFarlane <macfarla.github@gmail.com>
…ck found (hyperledger#4582) * add specific error for block by hash lookup not found Signed-off-by: Sally MacFarlane <macfarla.github@gmail.com> Signed-off-by: Sally MacFarlane <macfarla.github@gmail.com>
Previously were returning null in this case eg ethGetCode
New behavior matches geth 1.10.25
Do we consider this a breaking change?
Documentation
doc-change-required
label to this PR ifupdates are required.
Changelog