--prune.receipts.distance has no effect on Storage V2 nodes — receipts written to static files instead of DB

[dvs-one]

Describe the bug

On a Storage V2 node (default in reth v2.0.0+), setting "--prune.receipts.distance " has no effect. Receipts accumulate in static files indefinitely and are never pruned.

For Storage V2, receipts are only routed to the DB when receipts_log_filter is non-empty. The receipts field (set by --prune.receipts.distance) is not checked. This means distance-based receipt pruning is silently ignored on Storage V2 nodes.

Steps to reproduce

Run reth v2.0.0+ with:
--full --prune.receipts.distance 100800

After 14+ days, observe that reth_pruner_segments_highest_pruned_block{segment="Receipts"} is stuck at the static file boundary and receipts continue accumulating past the configured distance.

Observed metrics:

• rate(reth_database_operation_calls_total{table="Receipts",operation="cursor-delete-current"}[5m]) = consistently 0
• Single receipt static file growing continuously, no DB receipt pruning activity

Node logs

Platform(s)

Linux (x86)

Container Type

Docker

What version/commit are you on?

Reth Version: 2.0.0
Commit SHA: eb4c15e
Build Timestamp: 2026-04-07T12:47:39.107743398Z

(also present in v2.1.0 and v2.2.0 — the TODO comment in the Storage V2 branch suggests awareness of an adjacent issue but distance pruning was not addressed)

What database version are you on?

2

Which chain / network are you on?

mainnet

What type of node are you running?

Pruned with custom reth.toml config

What prune config do you use, if any?

[prune]
block_interval = 5
minimum_pruning_distance = 10064

[prune.segments]
sender_recovery = "full"

[prune.segments.receipts]
distance = 100800

[prune.segments.account_history]
distance = 10064

[prune.segments.storage_history]
distance = 10064

[prune.segments.bodies_history]
before = 15537394

If you've built Reth from source, provide the full command you used

No response

Code of Conduct

• I agree to follow the Code of Conduct

[0xMars42]

Dug into this. Root cause is in receipts_destination (crates/storage/provider/src/either_writer.rs):

if !receipts_in_static_files && prune_modes.has_receipts_pruning() ||
    // TODO: support writing receipts to static files with log filter pruning enabled
    receipts_in_static_files && !prune_modes.receipts_log_filter.is_empty()
{
    Database
} else {
    StaticFile
}

The V1 branch checks has_receipts_pruning() (distance + log filter), but the V2 branch only checks receipts_log_filter. So on a Storage V2 node with --prune.receipts.distance set and no log filter, receipts are routed to static files. prune_static_files then deletes whole jars below the target block, but with everything in one continuously growing jar there is nothing to delete, so distance pruning is a no-op. That matches the single static file growing continuously you observed.

Minimal fix: make the V2 branch consistent with V1 and with StaticFileProducer (which already checks both), i.e. receipts_in_static_files && prune_modes.has_receipts_pruning(), so distance-pruned receipts stay in the DB where row-level pruning works.

Before I open a PR: do you want them kept in the DB, or should receipts stay in static files and have distance pruning work at the jar level? Happy to do either.

cc @shekhirin @joshieDo