-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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: add get transaction by index methods #4579
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
@@ -76,14 +82,4 @@ pub enum ProviderError { | |||
/// The address is not owned by this node. | |||
#[error("{address} is not owned by this node")] | |||
UnknownAddress { address: Address }, | |||
/// Block number doesn't exist in blockchain |
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 replaced these with a single InvalidBlockNumberOrHash
as we only check if any of these match to return None
in the RPC and there will be many methods making this check.
pub async fn handle_get_transaction_by_block_hash_and_index( | ||
data: &ProviderData, | ||
block_hash: B256, | ||
index: U256, |
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'm curious whether the type used in the JSON-RPC type was correct. Does the standard specifically call for a U256
? I know I made some mistakes with other types where I used U256
but it turned out it's just a quantity
type with 1 or more values after the 0x..
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.
Good question. I went with U256
, because Hardhat accepts U256
as its rpcQuantity
type.
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.
Created follow up issue: NomicFoundation/edr#236
crates/edr_provider/src/data.rs
Outdated
} else { | ||
None | ||
}; | ||
|
||
Ok(transaction) | ||
} | ||
|
||
pub fn transaction_from_block( |
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 would have expected this logic to happen in the rpc handler, not here.
PS/Disclaimer: I didn't review the entire PR
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.
My thinking with the GetTransactionResult
(for which transaction_from_block
is a helper method) is this:
The transaction getter RPC methods need some data from the block (header stuff and the transaction index) in addition to the signed transaction. To avoid cloning entire blocks just to get a transaction, the GetTransactionResult
type exposes just the data needed by the transaction getter RPC methods in the internal representation (e.g. block number as u64
) and then lets the RPC methods convert to the data types expected in the RPC layer.
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.
Actually on second thought we cloning the block would be cheap, because it's behind an Arc
. But we still need a structure to return both the signed transaction and the block and I prefer explicit types.
Co-authored-by: Wodann <Wodann@users.noreply.github.com>
Co-authored-by: Wodann <Wodann@users.noreply.github.com>
Co-authored-by: Wodann <Wodann@users.noreply.github.com>
37d8a9f
to
90e252d
Compare
Add support for
eth_getTransactionByBlockHashAndIndex
andeth_getTransactionByBlockNumberAndIndex
: