Ah, it was a known bug but I was about to fix it when implemented saving mempool to db. When block prod is enabled it always recreates a pending block on startup, it can't restart exec from a current pending block.
I don't see how this would break explorers and other apps, i would guess this is something that be handled by their reorg handling.
But yea we need to fix that, what would you prefer between:

• On restart, continue the pending block, unchanged
• On restart, recreate a pending block and execute all of the transactions from the old pending block in the new pending block.

The second option would allow us to update the gas prices on restart (which would be useful after stopping for long), and would also allow us to change protocol version & other stuff across the restart if the configuration change, so that it's taken into account for this pending block and not the next one
However, any change in the header (like gas prices) could in theory make the transactions revert after restart, where we would have accepted them earlier.

For the first option, I believe we also have to reexecute the transactions because we can't supply the old state update & execution state to blockifier easily - the difference would only be that we don't recreate the block header

What do you think? @apoorvsadana

Thanks for this detailed explanation like always!

I don't see how this would break explorers and other apps, i would guess this is something that be handled by their reorg handling.

If the explorer has reorg handling, it mostly won't break but I can see issues happening if users can't trust pending receipts. For v0, block times will mostly be large because of proving costs but the reason that's fine is that we've pending receipts so you still get soft confirmations and good UX. For example, Pragma is considering doing hyperlane bridging with pending txs, if on restart the txn is lost, it can be a issue. cc @EvolveArt @akhercha.

However, any change in the header (like gas prices) could in theory make the transactions revert after restart, where we would have accepted them earlier.

You're right, I think we can't afford this for now because our block times are large so people will rely on pending receipts. So they need to be pretty strong confirmations. if there's a chance that it can be reverted, it will be difficult to create a good UX. So I would suggest we do option (1) if possible.