Unsafe revert in sc_client_api::backend::Backend doesn't revert finalized blocks

[shunsukew]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Description of bug

Unsafe revert in sc_client_api::backend::Backend doesn't work as expected.

It is described in the doc that "If revert_finalized is set it will attempt to revert past any finalized block".

However, providing true as its second arg doesn't revert finalized blocks.

Background

For local contract development node, we'd like to have revert RPC feature (not cli subcommand) for convenience.
However, it doesn't revert finalized blocks. https://github.com/AstarNetwork/swanky-node/pull/68/files#r1200247675

In below image case, finalized block # 100, and attempted to revert to block # 50 via RPC.
The diff number is 50 but they aren't reverted.

Steps to reproduce

No response

[andresilva]

The backend will not revert to blocks for which it doesn't have state, so if pruning is enabled it won't revert past the latest finalized block. I wrote a test and it worked when state was available. Try re-running with --pruning=archive to see if it works. I have to say though that even if the backend allows reverting finalized blocks it's likely that you'll find other breakage elsewhere (e.g. I'm almost certain that GRANDPA and BABE will break, Aura might work though). This isn't supported as there are too many places relying on the invariant that finalized blocks will not be reverted.

[shunsukew]

@andresilva
Thank you so much! and actually with --pruning archive reverting finalized blocks worked as expected.

I have an additional question now.
I use --state-pruning archive (without --block-pruning) and reverting finalized blocks succeeded.
However, If I read Substrate command doc, it says node keeps state of last 256 blocks by default.
So, if I understand correctly, without --state-pruning archive, it should be able to revert 256 finalized block at maximum? The reality is not.

--state-pruning <PRUNING_MODE>
          Specify the state pruning mode.
          This mode specifies when the block's state (ie, storage) should be pruned (ie, removed) from the database.
          This setting can only be set on the first creation of the database. Every subsequent run will load the pruning mode from the database and will error if the stored mode doesn't match this CLI value. It is fine to drop this CLI flag for subsequent runs.
          
          Possible values:
          - archive:
          Keep the state of all blocks.
          - 'archive-canonical'
          Keep only the state of finalized blocks.
          - number
          Keep the state of the last number of finalized blocks.
          [default: 256]

I have to say though that even if the backend allows reverting finalized blocks it's likely that you'll find other breakage elsewhere (e.g. I'm almost certain that GRANDPA and BABE will break, Aura might work though). This isn't supported as there are too many places relying on the invariant that finalized blocks will not be reverted.

I see, thank you so much for the explanation!

[juangirini]

This could continue as a Stack Exchange question