fatp: Implement blockchain revert handling

[AlexandruCihodaru]

Add support for handling blockchain revert. This is useful in testing.

Changes:

• Add ChainEvent::Reverted variant to represent backward blockchain progression
• Implement handle_reverted() method that:
  • Collects transactions from retracted blocks via included_transactions cache or by fetching block bodies from the API
  • Removes all views beyond the revert point to prevent zombie views
  • Removes included transactions from mempool (they can be resubmitted later)
  • Updates enactment state (recent_finalized_block and recent_best_block)
  • Ensures a valid view exists at the revert target block
• Add early return in maintain() for Reverted events to prevent normal forward-progression logic from running

These changes fix issues where reverting would leave zombie views in the view store, causing issues at subsequent operations.

Note: Transactions that were pending may not be visible after revert if they fail the revalidation

[AlexandruCihodaru]

/cmd fmt

[AlexandruCihodaru]

/cmd prdoc --audience runtime_dev --bump patch

[michalkucharczyk]

DQ:

          D1-E1-F1-G1-..-X1
         /
A - B - C - D2-E2-F2-G2-..-X2
         \
          D3-E3-F3-G3-..-X3

Is it realistic scenario? Should we handle this properly? If we revert from X1 to B, shold we also remove all transactions included on D2-...-X2 and D3-...-X3 forks (as we do for D1-...-X1)?

If we assume that revert can only be called if there is single fork - should we somehow check this in handle_revert function? (or at least document it somehow).

[AlexandruCihodaru]

DQ:

          D1-E1-F1-G1-..-X1
         /
A - B - C - D2-E2-F2-G2-..-X2
         \
          D3-E3-F3-G3-..-X3

Is it realistic scenario? Should we handle this properly? If we revert from X1 to B, shold we also remove all transactions included on D2-...-X2 and D3-...-X3 forks (as we do for D1-...-X1)?

If we assume that revert can only be called if there is single fork - should we somehow check this in handle_revert function? (or at least document it somehow).

Excellent question. I think that in anvil it is not possible to have such a scenario but I believe that we should delete the transactions on all possible paths.

[michalkucharczyk]

Would be nice to have some more information on the impact of this event to the internal state of the pool, e.g. all included transaction will be removed from the pool, what forks are removed (all or only one defined by tree_route param).

[iulianbarbu]

all included transaction will be removed from the pool, what forks are removed

Do you think about more than logging information about how many txs and forks are removed, as in a metric that can be queried later? Given that revert is mostly useful currently in anvil context, I would just add some more logging about the # of reverted forks and the reverted txs on all forks.

[iulianbarbu]

Looks good in general. It would be great to capture in the event the idea of reverting all existing forks, to have this logic appliable not just to single chain nodes like anvil-polkadot - but tbh not super sure how difficult it is.

[iulianbarbu]

all included transaction will be removed from the pool, what forks are removed

Do you think about more than logging information about how many txs and forks are removed, as in a metric that can be queried later? Given that revert is mostly useful currently in anvil context, I would just add some more logging about the # of reverted forks and the reverted txs on all forks.

[AlexandruCihodaru]

/cmd fmt

[AlexandruCihodaru]

/cmd fmt

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/19868343219
Failed job name: fmt

[AlexandruCihodaru]

/cmd fmt