[wip] execution/stagedsync: clear BlockAccessList on exec reset

[AskAlexSharov]

ResetExec (used by integration stage_exec --reset) is meant to clear all execution-written state, but BlockAccessList was missing from the cleanup list — so stale block access lists survived a from-0 exec reset.

This adds kv.BlockAccessList to stateHistoryBuckets, alongside ChangeSets3 (already present). Those two are exactly the raw exec-history tables pruned together by PruneExecutionBlockHistory.

For completeness, the rest of what the Execution stage writes is already covered: the 6 domains plus their history/inverted-index tables via DomainTables(...), the 4 standalone inverted indexes via InvertedIdxTables(...), and the pruning-progress tables. MaxTxNum is intentionally not here — it is a block-level index owned by the bodies/blocks reset (TruncateBodies + snapshot refill), not by execution.

[Giulio2002]

LGTM — straightforward reset-path fix to clear BlockAccessList alongside the other state/history buckets.

[Giulio2002]

LGTM — reset now clears BlockAccessList alongside the other state-history buckets, which is the obvious missing bucket.

[Giulio2002]

LGTM — exec reset should also clear BlockAccessList state history.

[Giulio2002]

LGTM — exec reset should clear BlockAccessList alongside the other stage-history buckets.

[Giulio2002]

LGTM — obvious one-line reset fix: clear BlockAccessList alongside the other state-history buckets during exec reset.

[Giulio2002]

LGTM — straightforward reset fix: clear BlockAccessList alongside the other state-history buckets.

[Copilot]

Pull request overview

Ensures ResetExec (used by integration stage_exec --reset) fully clears execution-owned history by including kv.BlockAccessList in the list of tables wiped during an execution reset, preventing stale block access lists from surviving a from-0 reset.

Changes:

• Add kv.BlockAccessList to stateHistoryBuckets so it is cleared by ResetExec alongside kv.ChangeSets3.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[yperbasis]

Questioning the premise here.

ResetExec is described as clearing execution-written state — but BlockAccessList isn't that. Its only production writer is InsertBlocks (execmodule/inserters.go:148), the block-insertion path; the Execution stage only reads it (exec3.go:597) and never writes it. So unlike its new neighbor ChangeSets3 — genuine exec output (WriteDiffSet, db/state/temporal_mem_batch.go:826) that re-exec regenerates — a cleared BAL is not regenerated by stage_exec. It isn't snapshotted either, so stage_exec --reset && stage_exec permanently drops it: eth_getBlockAccessList then returns 4444 and eth/71 answers 0x80 for those blocks until they're re-inserted.

It's block-level data by the same test the description uses to exclude MaxTxNum: keyed by BlockBodyKey(num,hash), deleted in DeleteBody (accessors_chain.go:701) and truncated in TruncateBlocks/PruneBlocks (952/901) right next to BlockBody/Headers. The blocks reset already clears it (ResetBlocks → TruncateBlocks), with re-insertion as the regeneration path.

Question: what regenerates these BALs after an exec-only reset? If nothing does, this belongs on the blocks reset (where it already is), not on ResetExec.

Nit: PruneExecutionBlockHistory in the description doesn't exist — the function is PruneExecutionStage.

[AskAlexSharov]

@yperbasis stage_exec.go pruning it now. i don't know why.

[Giulio2002]

LGTM — obvious one-line reset fix: BlockAccessList should be cleared together with the other state-history buckets on exec reset.

[Giulio2002]

LGTM — trivial reset-bucket fix: BlockAccessList is now cleared alongside the other execution/state history buckets.

[taratorio]

@yperbasis stage_exec.go pruning it now. i don't know why.

BALs is just optional data for quicker execution. If it is not there we will exec ok, if it is there we use it and exec quicker.

We keep it in mdbx for reorg range T-96. So that we do quicker re-execs when re-orging. When outside of T-96 we regenerate it by doing re-exec, e.g. #21764 so that we can respond to devp2p/jsonrpc requests for serving BALs.

BALs is more of a block body attachment. So maybe makes more sense to add it to integration stage_bodies --reset instead? We may want to keep BALs for integration stage_exec re-runs of blocks for e.g. performance benchmarking of exec with BALs.

[Giulio2002]

LGTM — obvious reset-bucket fix: BlockAccessList should be cleared alongside the other execution/state history buckets during exec reset.

[Giulio2002]

LGTM — obvious one-line reset fix: BlockAccessList should be cleared together with the other stage-reset buckets.

[Giulio2002]

LGTM — small, obviously low-risk diff (1 changed lines across 1 files)

[AskAlexSharov]

closing as no time to work on it