When enableMajorityReadConcern is set to false, we set the stable timestamp to the allCommitted timestamp. During rollbackViaRefetch, which is the rollback algorithm used when EMRC=false, we will force the stable timestamp backwards to the rollback common point. After this, we will also set the initial data timestamp to an optime ahead of us so that we don't take a new stable checkpoint until we reach a suitable timestamp. It is possible, however, for us to receive a heartbeat while we are in the middle of rollback, after we have forced the stable timestamp back to the common point. If our current view of the commit point is empty (i.e. the null optime), and the commit point sent to us has a term that matches our lastApplied (which could happen, for example, if the commit point was equal to the common point), then we will advance our commit point. When we try to update the stable timestamp, we will set the stable timestamp to the allCommitted, even if we don't update our committed snapshot. This means that our stable timestamp may be set forward to the top of the oplog in the middle of rollback, causing a stable checkpoint to be taken too far in the future, which violates the expectations of rollbackViaRefetch. We may then try to commit writes with timestamps behind the stable timestamp. To address this, we should likely prevent the stable timestamp from being altered by components external to rollback if we are currently in the rollback state, similar to what we do when EMRC=true.