feat(provider, prune): return receipts log filter#19630
feat(provider, prune): return receipts log filter#19630
Conversation
CodSpeed Performance ReportMerging #19630 will improve performances by 33.22%Comparing Summary
Benchmarks breakdown
|
a83211e to
b64b8ad
Compare
b64b8ad to
39c1f0e
Compare
af63c54 to
2d9300f
Compare
a928c07 to
5256e00
Compare
| #[derive(Debug, EnumIs)] | ||
| #[allow(missing_docs)] | ||
| pub enum EitherWriterDestination { | ||
| Database, | ||
| StaticFile, | ||
| } |
There was a problem hiding this comment.
this type is out of order
| } | ||
|
|
||
| impl EitherWriter<'_, (), ()> { | ||
| /// Returns the destination for writing receipts. |
There was a problem hiding this comment.
this needs docs about what the rules are here
crates/prune/types/src/segment.rs
Outdated
| #[error("the configuration provided for {0} is invalid")] | ||
| Configuration(PruneSegment), | ||
| /// Unsupported receipts log filter prune mode for address. | ||
| #[error("distance prune mode is not supported for receipts log filter, check address {0}")] |
There was a problem hiding this comment.
what should be checked here with the address?
There was a problem hiding this comment.
is this what we had previously?
can we reference the previous pr in the pr description?
e0b9e21 to
e679fbd
Compare
Co-authored-by: joshieDo <93316087+joshieDo@users.noreply.github.com>
| @@ -84,2 +83,2 @@ | |||
| .segment_opt(receipts.map(UserReceipts::new)) | |||
There was a problem hiding this comment.
do we no longer need the following?
// Receipts by logs
.segment_opt(
(!receipts_log_filter.is_empty())
.then(|| ReceiptsByLogs::new(receipts_log_filter.clone())),
)
There was a problem hiding this comment.
nope, because we don't have a prune segment anymore! Pruning for receipts log filter is now handled at the time of writing.
There was a problem hiding this comment.
dont we follow the MINIMUM_PRUNING_DISTANCE "rule", so we do need the pruner to remove the other receipts once its out of that range no?
…igmxyz/reth into alexey/receipts-log-filter-is-back
|
@shekhirin can we close this PR? I see the linked issue was closed also |
|
@shekhirin do we still want this? |
|
No one needs this |
Fixes #19621
This PR returns the previously removed receipts log filter pruning, but makes it work only with
FullandBeforeprune modes. Most of the changes are reverted from #19184.We're returning it, because some stakers depend on having receipts from certain staking protocols, and they don't want to store all 300GB+ of receipts on Mainnet.
We don't have
Distanceprune mode for this segment anymore because it's not useful for the type of pruning stakers do, and for us to support it, we would need to add a prune segment back.FullandBeforemodes work without a separate pruning segment, writing only specific receipts at the time of persisting.