primitives: use alloy Receipts with Option
#12162
Conversation
Co-authored-by: joshieDo <[email protected]>
|
@mattsse Nice bump here, is it ready to merge if I fix conflicts? |
| receipts: Receipts::from(value.0.receipts), | ||
| receipts: value.0.receipts.into_iter().map(Some).collect::<Vec<_>>().into(), |
There was a problem hiding this comment.
this new syntax is more complicated, I'm missing the point of this change
There was a problem hiding this comment.
Before we had this implemented in reth
impl From<Vec<Receipt>> for Receipts {
fn from(block_receipts: Vec<Receipt>) -> Self {
Self { receipt_vec: vec![block_receipts.into_iter().map(Option::Some).collect()] }
}
}but now the situation is more generic in alloy with a generic parameter T https://github.com/alloy-rs/alloy/blob/86812dba8507e6f7741f666303a53cafef93c8c1/crates/consensus/src/receipt/receipts.rs#L81 so that this is not available anymore. But this should just be a temporary situation since we would like to remove soon the Option<> in the definition of Receipts in reth after the merge of this PR and some follow up work
There was a problem hiding this comment.
The goal is was to use directly the alloy type, just importing it:
- Use the Receipts alloy type everywhere with
pub type Receipts = alloy_consensus::Receipts<Option<Receipt>>; - Do some work to arrive at
pub type Receipts = alloy_consensus::Receipts<Receipt>;(especially on pruning which is blocker right now)
But if we want to integrate a new Receipts type into reth maybe this PR is not relevant anymore
There was a problem hiding this comment.
I would hold off a bit with this pr until we have gotten further underway with #12454
|
I would say the codebase is ripe for his pr now. @tcoratger do you have capacity to pick it up again? |
Should close #7238
Superseed #12059