fix(pruner): prune account and storage changeset static files

[Rjected]

When account/storage changesets are stored in static files (rather than MDBX), the pruner now correctly reads from the static file provider and deletes the corresponding jars. Previously, pruning would silently skip these changesets since they weren't present in the database tables.

Adds an equivalent prune test for static files

[yongkangc]

one question is whether rocksdb would make use of this impl as well under AccountHistory

[Rjected]

I think yes it should

[Rjected]

I think yes it should

[yongkangc]

i guess this is the legacy implementation? not sure if we wanna add a note legacy as doc string

[yongkangc]

Suggested change

	let mut highest_deleted_storages: FxHashMap<_, _> = FxHashMap::default();
	let mut highest_deleted_storages = FxHashMap::default();

could we?

[yongkangc]

the logic looks really similar as the db one including the comments - not sure if we wanna dedup them in the future. just a note, not this pr tho

[Rjected]

could probably add a helper

[yongkangc]

Suggested change

	let mut highest_deleted_accounts: FxHashMap<_, _> = FxHashMap::default();
	let mut highest_deleted_accounts = FxHashMap::default();

could we?

[yongkangc]

makes sense

the logic of account, storage changesets looks realy smiliar to mdbx ones, not sure if we can dedup them in the futture

[joshieDo]

starting here and below could be dedupped with the mdbx implementation. but unsure if then @yongkangc would even use it

[joshieDo]

same for storage history

[joshieDo]

oops, has been mentioned already

[Rjected]

btw added reuse for this ptal

[gakonst]

[MAJOR] account_history.rs:79 - Significant code duplication between prune_static_files() and prune_database().

Both methods share ~60% identical logic:

• Lines 89-100 (limiter setup + early return) duplicated at lines 176-187
• Lines 133-146 (checkpoint calculation + sharded key sorting) duplicated at lines 211-224
• Lines 147-163 (history index pruning + output construction) duplicated at lines 225-242

Consider extracting shared logic into helper methods:

1. setup_limiter(input, tables_count) -> (PruneLimiter, Option<SegmentOutput>) for the early return pattern
2. finalize_prune(highest_deleted_accounts, last_block, done, range_end, limiter) -> SegmentOutput for the common tail

This would make prune_static_files() and prune_database() only differ in their changeset iteration logic (~20 lines each), making the actual difference between static file vs database pruning much clearer.

Action: Should fix

[gakonst]

[MAJOR] storage_history.rs:79 - Same duplication pattern as account_history.rs.

prune_static_files() (lines 79-171) and prune_database() (lines 173-253) share nearly identical:

• Limiter setup and early return logic
• Checkpoint calculation with the done flag adjustment
• Sharded key sorting and history index pruning
• Output construction

The only real difference is:

• Static files: iterating via walk_storage_changeset_range() walker
• Database: iterating via prune_table_with_range()

Consider a shared helper or a strategy pattern to avoid the duplication.

Action: Should fix

[gakonst]

[MINOR] account_history.rs:89-100 - The limiter adjustment pattern is duplicated 4x across both files.

This exact pattern appears at:

• account_history.rs:89-100 (prune_static_files)
• account_history.rs:176-187 (prune_database)
• storage_history.rs:89-100 (prune_static_files)
• storage_history.rs:183-194 (prune_database)

Consider extracting to a helper:

fn adjust_limiter_for_tables(
    input: PruneInput,
    tables_to_prune: usize,
) -> Result<PruneLimiter, SegmentOutput> {
    let mut limiter = if let Some(limit) = input.limiter.deleted_entries_limit() {
        input.limiter.set_deleted_entries_limit(limit / tables_to_prune)
    } else {
        input.limiter
    };
    
    if limiter.is_limit_reached() {
        return Err(SegmentOutput::not_done(
            limiter.interrupt_reason(),
            input.previous_checkpoint.map(SegmentOutputCheckpoint::from_prune_checkpoint),
        ));
    }
    Ok(limiter)
}

Action: Should fix (part of the larger dedup effort)

[gakonst]

Review Summary: Abstraction Quality & Code Duplication

Issues Found

Severity	File	Line(s)	Issue
MAJOR	account_history.rs	79-242	~60% code duplication between prune_static_files() and prune_database()
MAJOR	storage_history.rs	79-253	Same duplication pattern as account_history.rs
MAJOR	Both files	-	Cross-file duplication: both files implement nearly identical structures
MINOR	account_history.rs	89-100	Limiter adjustment pattern duplicated 4x across both files
NIT	account_history.rs	102, 193	Typo: "it's" should be "is"
NIT	account_history.rs	125	Comment restates what the code does (same in storage_history.rs:127)

What's Good

• Comments explain "why" not "what": The memory size estimation comments and the BTreeMap inefficiency explanation are valuable
• Naming is clear: highest_deleted_accounts, last_changeset_pruned_block, prune_static_files vs prune_database are all self-documenting
• No unnecessary abstractions: No single-use traits or premature indirection

Recommendation

The main issue is that the new static file pruning path introduced significant duplication. Per Ousterhout's principles, this creates maintenance burden - any bug fix or enhancement will need to be applied in 4+ places. Consider:

1. Short-term: Extract shared limiter setup and finalization logic into helper methods
2. Long-term (optional): A generic HistoryPruner<T> that parameterizes over the table/key types

[yongkangc]

we might want to add a comment here indicating this is for mdbx since we have rocksdb pruning as well?

[joshieDo]

lgtm