We should look into using lastOpTimeFetched rather than lastOpTimeApplied for election purposes. In particular, candidates for election would use it for the "lastLogIndex" field of the RAFT RequestVote RPC and voters would refuse to vote for anyone who is behind their lastOpTimeFetched. I think this will avoid the odd case where a majority of nodes can accept an op and apply it, but it will still be rolled back. I think this also is closer to my reading of RAFT's log[] state given the way that we split the AppendEntries RPC with the "request" being the reply from a getMore and the "reply" being the upatePosition command request.