Skip to content

Better integration tests for unwind issues #21860

Description

@yperbasis

Recently we've been plagued with unwind/re-org issues (e.g. #20169, #20995, #21515, #21681, #22399), so we clearly need to improve our integration tests to catch them earlier. In particular, we need to tests re-orgs with pruning interfering (see #21824).


Status (updated 2026-07-07)

Every root-cause fix behind the incidents above was revert-tested against the integration suite to find which failure classes the tests actually catch. Coverage landed in two PRs:

Bugs surfaced by writing these tests

Each comes with a ready-made red test described in the issue:

Remaining test work

Production hardening

For the classes that revert-testing proved unreachable from outside on current main (the cleared-markers ordering has no producer — the FCU unwinds before rewriting markers in one atomic tx; the no-op-unwind overlay-prune branch is shielded by FCU-tx rollback plus a fresh SharedDomains per FCU), the stage-level tests remain the guards. To keep future refactors honest:

Smaller items

  • Tighten TestDomain_DeletedKeyNotResurrectedByFiles: it does not go red on the getLatestFromDb tombstone-as-miss revert it is named for (the invariant is actually pinned by TestDomain_UnwindRestoresDeletionMarker and the multi-step unwind test).
  • Optional: a reverting-CREATE clause in the StateChurn contract to bring the journal code-size revert class (execution: revert CodeSizePath in codeChange journal entry #20039, EXTCODESIZE after a reverted CREATE) in-house; currently guarded only by the EEST suite in CI.

Known, accepted limitation

The #20483 write side (an unwind losing deletion tombstones) is not observable at any integration-test scale: unmerged snapshot-file layers retain deletion markers, so the loss self-heals (verified by instrumentation — hundreds of skipped tombstone restores with no observable effect, even with file freezing forced). The production resurrection required mainnet-scale compaction. TestDomain_UnwindRestoresDeletionMarker remains its guard.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions