Benjamin Wang

> I think the result is that this PR has no significant effect on the average time to recovery of etcd. > There are some subtle changes in the tail...

cc @pav-kv @erikgrinaker PTAL

> I assume the motivation of this change comes from [etcd-io/etcd#17455](https://github.com/etcd-io/etcd/issues/17455). Yes. > When such a node does not reset its election timeout, it may quickly start a new campaign...

Prefer to the alternative PR https://github.com/etcd-io/raft/pull/169, - #169 has better readability than this PR - In this PR, the local node's term has already increased by 1 even it rejects...

> Upd: I guess we do need to sometimes reset it, because of [#167 (comment)](https://github.com/etcd-io/raft/pull/167#issuecomment-1955813036). YES, it's one of the reasons why I prefer to https://github.com/etcd-io/raft/pull/169. The other reason is...

Please rebase this PR, I will take a look later.

> To implement approach (2), `raft` needs to export/delegate the notion of "leader->follower flow" in such a way that the application layer can drive it. It would be similar to...

This PR might lead to subtle availability issues. Under the existing election timeout mechanism, each member only votes once in each term, accordingly at most one leader will be elected...

cc @nvanbenschoten

Rough plan: - Release 3.6.0-alpha.0. Will not cut branch, and it will be released against the main branch. - Please advise what need to be resolved before we release 3.6.0-alpha.0....