Replicated logs: match a prefix before extending it

AppendEntries includes the index and term of the entry immediately before the entries being sent. A follower first checks the request term and the predecessor match. If the predecessor is absent or has a different term, the follower rejects rather than pretending an extension can be spliced onto an unrelated history. The leader then adjusts its replication position for that follower; implementations may return conflict hints to avoid retrying one index at a time. Such optimizations must preserve the same matching requirement.

Raft's log-matching property says that if two logs contain an entry with the same index and term, their entries agree through that position. The argument relies on one legitimate leader per term creating entries consistently and on followers accepting extensions only after a matching predecessor. Comparing two arbitrary files with the same numeric annotation would not prove their bytes equal. Likewise, a checksum detects some corruption but does not replace the protocol's history invariant or its non-Byzantine assumptions.

After a successful predecessor check, a follower compares incoming entries with any entries at those indices. At the first same-index, different-term conflict, it deletes that conflicting entry and its following suffix, then appends the incoming continuation. Entries that already match need not be rewritten. A heartbeat or a shorter duplicate request must not automatically delete an otherwise valid longer suffix merely because the request did not mention it. The trigger is an actual conflict with a supplied entry, not the end of a message.

The leader maintains follower-specific progress estimates and updates them from responses in the relevant term and request context. Delayed failure replies must not undo later knowledge carelessly. A follower's successful response represents the storage state required by the implementation's durability contract. An entry stored on one follower is not necessarily committed, and a repaired follower must apply only the committed ordered prefix. Correct Raft never repairs disagreement by overwriting an already committed command with a different command at the same index.

Follower catch-up has both correctness and capacity concerns. A leader generating entries faster than a follower can durably receive them creates lag, even if every AppendEntries exchange is correct. Batching, flow control, and snapshots can help, but must not let a follower acknowledge data it has not safely processed. Diagnose the longest blocked stage: transport, persistence, or application. Each lag metric describes a different boundary, and none can certify that a conflicting suffix was repaired correctly.

Use the queue lab only for a normalized replication-lag analogy. For a growing fixed-rate run choose Reset, explicitly set arrival four and service three, predict the backlog slope, then Play or Step. For a separate draining run Reset and explicitly set arrival two and service three before predicting and playing. Rate edits preserve elapsed time and recompute from four initial items; they do not continue a prior backlog with a new rate. The lab contains no log entries, terms, predecessor checks, or conflict repair.