How raft algorithm maintains strong read consistency in case of a node become leader and it have an uncommitted log entry

Question

Consider five nodes(S1,S2,S3,S4,S5) getting key/value data. And the following steps happened

1. S3 becomes leader and client write a key equal 2 to cluster
2. S3 append entry to S1,S2,S4,S5, then S1,S2,S4,S5 accept it and write entry to itself log（as shown in the picture 1）
3. S3 received majority response(from S1,S2,S4,S5), S3 commit entity that key equal 2, and send write succeed message to client, and then send commit message to S1,S2,S4,S5
4. S2,S4,S5 received commit message and commit entry success, but S1 crashed. just like in picture 2, S1 will have an uncommitted entry.
5. Now, S1 restart and become a leader with an uncommitted entry that key equal 2(as shown in the picture 3)

After above steps, client query an entry(key equal 2, just wrote succeed). But now S1 is leader and key equal 2 entry is uncommitted. So, client will can't find entry that itself wrote a moment ago. So, where I made a mistake? please help me (picture 1) (picture 2) (picture 3)

Answer 1

I have found the solution at Diego Ongaro paper more detailed version In Search of an Understandable Consensus Algorithm(Extended Version) . In section 8(Client interaction), I found the answer, Raft handles this by having each leader commit a blank no-op entry into the log at the start of its term. After this, In question S1 will commit log index equal 1 entry by commit a blank no-op entry.