The response to the client is only sent after a majority of followers have the log entry. That's described in the text in the "Protocol Overview", and nicely animated in "Log Replication".
Yes, they have the log entry, but it can still be rolled back, can't it? Here's how I understand the process:
1. Client sends log entry to leader
2. Leader appends log entry, forwards it to followers
3. Majority of followers confirm
4. Leader commits the log entry
5. Leader confirms the commit to the client
6. Followers commit on the next heartbeat
What happens if the leader goes away between 5 and 6? To my eyes, it looks like the followers will time out, elect a new leader, and have to roll back the last log entry.
If an entry has been replicated to a majority of followers, then the new leader is guaranteed to have that entry and therefore it won't be rolled back.
That is correct. The solution to this is given in section 5.4.1 (election restriction), section 5.4.2 (Committing entries from previous terms) and section 8 (Client interaction) of the Raft paper.
Roughly, a newly elected leader will have all committed entries (guaranteed by the "election restriction", 5.4.2) but it does not know precisely which are committed. The new leader will commit a no-op log entry (section 8) and after it has received replies from a majority of the cluster it will know which entries have already been committed.
1. Client sends log entry to leader
2. Leader appends log entry, forwards it to followers
3. Majority of followers confirm
4. Leader commits the log entry
5. Leader confirms the commit to the client
6. Followers commit on the next heartbeat
What happens if the leader goes away between 5 and 6? To my eyes, it looks like the followers will time out, elect a new leader, and have to roll back the last log entry.