nested invalidate block doesn't work like I expect #10439

If I invalidate block 5 it reorgs to block 4 as expected. If I then invalidate block 4 it reorgs to block 3, as expected. If I reconsider 4 I expect it to go back to 4, as 5 is still invalidated, but instead it reorgs back to the best tip.

Read the RPC help text from reconsiderblock:

reconsiderblock "blockhash"

Removes invalidity status of a block and its descendants, reconsider them for activation.
This can be used to undo the effects of invalidateblock.

reconsiderblock automatically applies to all descendants of a block, so this is working as intended. There is no such thing as priorities when invalidating/reconsidering. Just valid and invalid.

An alternative would be to have reconsiderblock only apply to the ancestors of a block and not its descendants. That would get you the ability to selectively reconsider, but it would result in a sequence (where the tip block is 10)

invalidateblock 8
reconsiderblock 8

to make 8 the new tip instead of 10, as 9 and 10 would remain invalid.

Not applying reconsiderblock to descendants seems rather tedious for the "roll back to create UTXO snapshot" use case: #15606. Though there could be an additional argument to include descendants.

If block 8 can be invalid and block 10 can be invalid, we'd have to change the "children of BLOCK_FAILED_VALID may be BLOCK_FAILED_CHILD, but must not be BLOCK_FAILED_VALID" rule. See #16856.

I'm fine with the current behavior, though not opposed to changing it.

While reviewing #26260 I came back here to see if the issue was related at all... I think I agree with Sipa and Sjors that the current behavior is expected and documented and this issue should probably closed as "won't fix"

Ok, closing for now due to lack of interest, progress and direction.

Pull requests with improvements are always welcome. Moreover, it is possible to re-open this issue or create a new issue referencing it, if there is fresh interest.