-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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: remove constraint of concrete type AnyTransactionReceipt for EthApiTypes::NetworkType #10693
Conversation
need to fix build error |
128802c
to
78d866e
Compare
crates/rpc/rpc-builder/src/lib.rs
Outdated
@@ -1100,7 +1119,8 @@ where | |||
) | |||
.into_rpc() | |||
.into(), | |||
RethRpcModule::Ots => OtterscanApi::new(eth_api.clone()).into_rpc().into(), | |||
RethRpcModule::Ots => todo!(), /* OtterscanApi::new(eth_api.clone()). */ | |||
// into_rpc().into(), |
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.
@emhane I don't know how to address this. the error info #10693 (comment)
@emhane, sorry for that, I use force push.I just want to re implement. |
this is requiring that receipt type taken from reth/crates/rpc/rpc-eth-api/src/core.rs Lines 365 to 372 in b0fddef
EthApiTypes is a super trait of FullEthApi reth/crates/rpc/rpc-eth-api/src/helpers/mod.rs Lines 52 to 56 in b0fddef
|
crates/rpc/rpc-builder/src/lib.rs
Outdated
EthApi: EthApiServer< | ||
reth_rpc_types::Transaction, | ||
reth_rpc_types::Block, | ||
reth_rpc_types::AnyTransactionReceipt, | ||
>, | ||
RpcTransaction<EthApi::NetworkTypes>, | ||
RpcBlock<EthApi::NetworkTypes>, | ||
RpcReceipt<EthApi::NetworkTypes>, | ||
> + EthApiTypes< | ||
NetworkTypes: alloy_network::Network< | ||
TransactionResponse = reth_rpc_types::Transaction, | ||
HeaderResponse = reth_rpc_types::Header, | ||
ReceiptResponse = AnyTransactionReceipt, | ||
>, | ||
>, |
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.
leave concrete types for transaction and block for now everywhere, only relax the constraint on receipt. so we want
EthApi: EthApiServer<
reth_rpc_types::Transaction,
reth_rpc_types::Block,
RpcReceipt<EthApi::NetworkTypes>,
>,
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.
Got it. I will address this.
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 alloy-rs/alloy#1245
@@ -369,7 +369,7 @@ impl<T> | |||
RpcReceipt<T::NetworkTypes>, | |||
> for T | |||
where | |||
T: FullEthApi, | |||
T: FullEthApi<NetworkTypes: Network<ReceiptResponse = AnyTransactionReceipt>>, |
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 the opposite of what we want, we want to remove this constraint. however, the possibility of doing so depends partly on alloy-rs/alloy#1245.
@@ -76,6 +79,7 @@ where | |||
> + EthApiTypes< | |||
NetworkTypes: Network< | |||
TransactionResponse = WithOtherFields<reth_rpc_types::Transaction>, | |||
ReceiptResponse = AnyTransactionReceipt, |
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 constraint can now be removed since alloy-rs/alloy#1245 is closed. the new trait methods on alloy_network_primitives::ReceiptResponse
should be enough to access fields on the receipt throughout this OtterscanServer
impl.
Thanks. Got it. |
you know what, a better approach here is to change the description to "Ref <issue>" instead of "Closes <issue>", and merge this PR :) |
Thanks for correcting me. I saw many guys use |
no worries, close is for when the issue is solved, and ref when it is related e.g. partly solves the issue |
Ref #10632