-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
feat: Include missing block id in error responses #7416
feat: Include missing block id in error responses #7416
Conversation
a2ecd95
to
e8a3335
Compare
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.
this is great, ty!
one pedantic style nit
do we always want to include the unknown block id
prefix?
I don't think this matches geth?
crates/rpc/rpc/src/eth/api/mod.rs
Outdated
ProviderError::HeaderNotFound(_) => EthApiError::UnknownBlockId(at), | ||
ProviderError::BlockHashNotFound(_) => EthApiError::UnknownBlockId(at), |
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.
style: these can be combined into one arm: ProviderError::HeaderNotFound(_) | ProviderError::BlockHashNotFound(_)
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.
cab8251
to
3a91c22
Compare
Personally I'm not convinced we should try to sync up exact error messages, just codes (and as you pointed out EIP-1474 clearly shows we should return |
Actually
I suppose we could make the error message |
hmm, yeah rpc error inconsistencies are very annoying, I think we should mimic geth's messages but can include the number or hash |
Hey @ryanschneider, any blocker here? Let me know so we can get this merged 😄 |
Sorry @onbjerg I've been away for a bit but am hoping to get back to this soon, however in rebasing off main I saw #8045 which definitely complicates this PR, seems like changing the error response might break. The comment in main mentions ethereum-optimism/optimism#10071 but that PR was closed w/ a mention of the issue being fixed in another PR, but I've lost the thread after that. @mattsse I think we settled on the error text being:
|
latter can be simplified: |
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, would you like help fixing merge conflicts?
oh yeah, sorry we let this go stale... we still want this, please take over @emhane |
seems like a bug in geth or alloy then? |
finally fixed all conflicts here! re-request review also @mattsse |
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.
overall lgtm but please remove the unrelated changes
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.
a few nits, and I want to see full error messages in tests, otherwise it is now non trivial to reason about what we're actually returning as the error.
@@ -24,7 +24,7 @@ pub trait Otterscan { | |||
|
|||
/// Check if a certain address contains a deployed code. | |||
#[method(name = "hasCode")] | |||
async fn has_code(&self, address: Address, block_number: Option<u64>) -> RpcResult<bool>; | |||
async fn has_code(&self, address: Address, block_id: Option<BlockId>) -> RpcResult<bool>; |
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.
this is incorrect, this makes it incompatible with the otterscan API this must be u64 not hex
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.
okay this is actually no longer the case, so BlockId is correct now
https://otterscan.github.io/execution-apis/api-documentation/
/// Thrown when querying for `finalized` or `safe` block before the merge transition is | ||
/// finalized, <https://github.com/ethereum/execution-apis/blob/6d17705a875e52c26826124c2a8a15ed542aeca2/src/schemas/block.yaml#L109> | ||
/// | ||
/// op-node now checks for either `Unknown block` OR `unknown block`: | ||
/// <https://github.com/ethereum-optimism/optimism/blob/3b374c292e2b05cc51b52212ba68dd88ffce2a3b/op-service/sources/l2_client.go#L105> | ||
/// | ||
/// TODO(#8045): Temporary, until a version of <https://github.com/ethereum-optimism/optimism/pull/10071> is pushed through that doesn't require this to figure out the EL sync status. |
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.
we're changing the error now, does this affect op logic?
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.
input pls @joshie as author of ethereum-optimism/optimism#10071
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.
blocked by ethereum-optimism/optimism#11759 |
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.
tysm @emhane 🙏
I think we shouldn't block on the op pr
@@ -24,7 +24,7 @@ pub trait Otterscan { | |||
|
|||
/// Check if a certain address contains a deployed code. | |||
#[method(name = "hasCode")] | |||
async fn has_code(&self, address: Address, block_number: Option<u64>) -> RpcResult<bool>; | |||
async fn has_code(&self, address: Address, block_id: Option<BlockId>) -> RpcResult<bool>; |
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.
okay this is actually no longer the case, so BlockId is correct now
https://otterscan.github.io/execution-apis/api-documentation/
Yup thanks @emhane for getting this over the finish line! |
Fixes #7368 which explicitly mentions
eth_call
, but also updates:eth_call
eth_getStorageAt
eth_getProof
(see below)eth_getTransactionCount
eth_getCode
eth_getBalance
eth_createAccessList
debug_traceCall
trace_rawTransaction
trace_callMany
trace_call
In each case, the error response is of the form:
or
Testing performed for the above w/
cast
andcurl
here: https://gist.github.com/ryanschneider/20e8f78e46666d8249d266abec118f6aFor
eth_getProof
I opted not to interfere with the current situation where only block_id's that resolve to"latest"
are supported.I'm 100% open to hearing about better ways to implement this, one thing I don't like is that
EthApiError::UnknownBlockNumber
responses can still get through, if there's a good way to leverage Rust types to prevent that I'm all ears.