[query]How etcd-raft gurantee the correctness of leased read

[kikimo]

Hi, I read the leader lease part of etcd-raft and it seems that the Leader was not expiring its leader lease when it was required to transfer its leadership. A transferer might just step back to leader(it has now a new leader lease of an election timeout long) and serve read-only reuqests after election timeout if now message from new leader was recieved. Suppose the transferee was elected leader just right after the transferer step back leader again, at this time both leader might be able to server read-only request and I think the old leader might return stale read-only results to clients.

[joshuazh-x]

raft guarantees at most one leader in each term. And in serving read-only query, leader will first check if it is the latest leader by casting heartbeat to all peers. Only the leader with newer term will be able to get quorum heartbeat responses and serve read-only query.

Following is quoted from Diego Ongaro's dissertation.

The leader needs to make sure it hasn’t been superseded by a newer leader of which it is
unaware. It issues a new round of heartbeats and waits for their acknowledgments from a
majority of the cluster.

[kikimo]

raft guarantees at most one leader in each term. And in serving read-only query, leader will first check if it is the latest leader by casting heartbeat to all peers. Only the leader with newer term will be able to get quorum heartbeat responses and serve read-only query.

Following is quoted from Diego Ongaro's dissertation.

The leader needs to make sure it hasn’t been superseded by a newer leader of which it is
unaware. It issues a new round of heartbeats and waits for their acknowledgments from a
majority of the cluster.

That's indexed read, but I'm talking about leased read.