Currently, we trigger rollback op observers after recovering to the stableTS, and resetting the lastApplied/lastDurable optimes. However, it's possible that we fail in the op observers, failing rollback but not resetting the lastFetchedOpTime. The consequence is that we end up retrying rollback but hanging indefinitely since Replication will first wait for the lastApplied to reach the lastFetchedOpTime before starting rollback. In this case, we wait to apply an oplog entry that no longe exists.

The server will only fail rollback and crash if the error returned is a UnrecoverableRollbackError and retry rollback otherwise. We tend to use rollback op observers to clean up on-disk state (as demonstrated in the linked BF), so if the procedure fails, we should instead crash on rollback failure instead of retrying.