When inserting a new trie root (or contract state hash) we were first pruning the old values (so that data that is out of the number-of-blocks-kept window is removed). The pruning functions make sure that there's at least one value kept at or before the first block of the availability window.
This was working correctly for non-zero number-of-blocks-kept values, but was causing missed removals for the no-history case. When number-of-block-kept is zero we were keeping the previous value (root / state hash) in addition to the new value we were being inserting. This lead to missing a required revert operation upon a one-block reorg because the global storage root index was still in place for the target block.
This change fixes this by reordering insertion of the new node and pruning. This way we correctly remove old values in the no-history case.
When inserting a new trie root (or contract state hash) we were first pruning the old values (so that data that is out of the number-of-blocks-kept window is removed). The pruning functions make sure that there's at least one value kept at or before the first block of the availability window.
This was working correctly for non-zero number-of-blocks-kept values, but was causing missed removals for the no-history case. When number-of-block-kept is zero we were keeping the previous value (root / state hash) in addition to the new value we were being inserting. This lead to missing a required revert operation upon a one-block reorg because the global storage root index was still in place for the target block.
This change fixes this by reordering insertion of the new node and pruning. This way we correctly remove old values in the no-history case.
Closes: #2110