There is only one version of the committed log. That's the definition of committed. So you won't get a committed write or read from a partitioned "zombie" lead

There is only one version of the committed log. That's the definition of committed. So you won't get a committed write or read from a partitioned "zombie" leader. In good (non-buggy) Raft implementations, things are set up so there can only ever be at most one leader at a time. That is the point of the election, the pre-vote, the leader-leases, the sticky-leader, and the leader-must-step-down rules (from chapter 6 of the dissertation). Yes those optimizations are described as optional in the Raft dissertation. But really they are not. You have to read the whole dissertation to the details and full picture. You should have all of them as a part of a complete and sane implementation. Pre-vote and sticky-leader are needed for liveness. Leader leases are possible because you have pre-vote and sticky leader on; and they give you fast local-only leader reads. The leader step-down rule prevents client liveness and multiple leaders at once. Even if you do have multiple leaders at once, only one will actually be able to commit, so its not a problem with safety or consistency, just with liveness/not wasting the client's time talking to "a dead man walking".