Three servers have the log entry. Why won't Raft commit it?

A majority count seems convincing

We just learned that a five-node group needs three voters to commit a new entry. So when a new leader sees an old entry on three nodes, the tempting answer is, "Yes, it has a majority."

That answer overlooks what changed between the entry's creation and this observation. Other candidates may hold conflicting entries from later terms. Raft must protect the history surviving future elections, not merely count current copies.

The Raft paper constructs a specific counterexample. An entry from an earlier term can reach a majority, yet a later candidate whose last log term is newer can still win an election and overwrite that entry. This is why an old-term entry cannot be declared committed solely by counting replicas after a leadership change.

There is an important qualification. An entry already known to be committed under the valid protocol remains committed. We are discussing a new leader trying to infer commitment for an earlier-term entry that was not previously known to be committed.

What the new leader actually checks

Each Raft log entry has an index and the term in which it was originally appended. A leader tracks how far each follower has replicated its log, often represented as a match index. For a candidate commit index N, the usual current-term commit rule asks whether a majority has stored entries through N and whether the leader's entry at N belongs to the current term.

In our example, index 41 belongs to term 6. Even if three nodes now show it, a term-7 leader does not directly advance the commit index to 41 by that count alone.

Instead, the new leader appends an entry from term 7. This might be a no-op command because the application has no new update. Suppose it lands at index 42 and is replicated on a majority. The leader can then commit index 42 because its term is 7. All preceding entries on that leader's consistent log, including index 41, become committed through the log-matching and election-safety rules.

It gives the leader a current-term entry to commit. If the leader has an ordinary client command in term 7, that could provide the same current-term boundary.

Why not simply change the old entry's term?

An entry's original term is part of how Raft verifies log matching across servers. Rewriting old entries with new term numbers would obscure histories that the protocol relies on to identify common prefixes and conflicting suffixes. Raft leaves older entries' terms intact and commits them indirectly once a sufficiently replicated current-term entry closes the uncertainty.

Distinguish an entry present on a follower from a follower knowing it is committed. A leader tells followers its commit index through replication messages, and followers apply committed entries to their state machines in order. Those are separate steps. An entry can be stored before it is committed, and committed before it is applied locally. Here the question is why the leader may advance commitment at all.

Suppose a follower persisted index 42 but has not yet received the leader's updated commit index. It cannot unilaterally promote arbitrary log bytes to committed application state merely because they occupy a familiar position. Equally, the leader's own matchIndex is not enough to treat a command as committed without the rest of the rule.

Elections protect history as well as choose a coordinator

Raft voters compare the candidate's last log term and then its index. A candidate with an obsolete log cannot win votes from a majority that would collectively preserve committed history. This election restriction works with the commit rule, not independently of it.

If two candidates request votes, the node with the longest log is not always the best candidate. A shorter log ending in a later term can be considered more up-to-date than a longer log ending in an earlier term. The longest log does not always win.

The leader never repairs the problem by letting followers vote on each entry independently. It replicates a coherent log with index-and-term matching, then advances a single committed prefix. Conflicting uncommitted suffixes may be replaced, while committed entries must remain present in every future legitimate leader's log.

How this changes an API answer

Imagine the term-7 leader receives setLimit(250) immediately after election. Its API should not promise completion just because it appended the command locally or because two replicas acknowledged bytes. It needs the appropriate quorum commit before acknowledging a successful state-changing decision. If the API returns the computed state-machine result, it also needs that command applied.

If the term-7 leader loses its quorum, it cannot commit new writes. The safe answer is sometimes to wait, redirect, or return an uncertain outcome rather than inventing a stronger guarantee.

The lesson is not that majority replication stopped mattering. A majority of copies is necessary evidence, but Raft also needs the right term and log history before declaring a new commit.

We have now protected decisions inside the replicated log. What if a worker obtains leadership through that log, pauses for a long time, and then writes directly to an external resource after losing the lease?