You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This fixes a "nearly" bug.
The contract of Progress.Match is that the index is durable. When
becoming leader, there is no guarantee that raftLog.lastIndex() is
durable locally. We could have got a quorum of votes, and yet the local
storage hasn't voted/synced yet. We only know that a log index is
durable when handling a self-MsgAppResp or a storage append ack.
This wasn't a real bug because raftLog.lastIndex() is an entry from
previous terms, and the first entry at our leader's term comes after it.
A leader can only commit entries from its own term (see maybeCommit), so
this opportunistically set Match could not cause false-positive commits.
But could be a bug if this lastIndex included the dummy entry, which is
appended a few instructions down the line.
There is no value in setting Match for the leader this way, and it
appears cleaner that Match is initialized empty and only updated by
MsgAppResp, symmetrically for all peers including self. For the leader,
it will be first updated when the dummy entry makes a durable roundtrip
to local storage.
Epic: none
Release note: none
0 commit comments