In recovery,.go, the VM will roll back indefinitely until it finds a block with the post-execution state committed. In the case of a bug or database corruption, this could roll back to genesis without any logs, or even worse, potentially underflow and loop indefinitely.
One solution would be to find a way to cap the number to look back, and if it's more than that, just give up and return an error. However, choosing such a number is difficult.
Let us assume your marked last executed block is at height E, and your last committed settled state is at height H, with commit interval C. We cannot assume E - H <= C, because the user may have changed their commit interval. An additional (handleable) detail is that we need to roll back to some X < H, since we need the post-execution state. This is computable at iteration time, but needs to be accounted for.
In
recovery,.go, the VM will roll back indefinitely until it finds a block with the post-execution state committed. In the case of a bug or database corruption, this could roll back to genesis without any logs, or even worse, potentially underflow and loop indefinitely.One solution would be to find a way to cap the number to look back, and if it's more than that, just give up and return an error. However, choosing such a number is difficult.
Let us assume your marked last executed block is at height
E, and your last committed settled state is at heightH, with commit intervalC. We cannot assumeE - H <= C, because the user may have changed their commit interval. An additional (handleable) detail is that we need to roll back to someX < H, since we need the post-execution state. This is computable at iteration time, but needs to be accounted for.