Thanks for this fix. To make sure if I understand this condition correctly, can you confirm the below?

Let's say the current committed index is 10 (for all pre-commit, quick-commit, and sm-commit), and two threads (T1 and T2) are calling handle_cli_req with exactly one log. What will happen is:

1. T1 calls handle_cli_req first, precommit_index_ becomes 11.
2. Before T1 creates the corresponding commit_ret_elem, the commit thread wakes up earlier.
3. Since sm_idx == pc_idx in this case, the commit thread will create it.
4. However, T2 cannot interfere before step (3), because of the lock held by handle_cli_req_prelock. T2 can append its log only after the commit_ret_elem for 11 is created.

So, if a thread order inversion happens, only one user thread is involved at a time. When the commit thread wakes up, there is no case that there are multiple handle_cli_req calls whose commit_ret_elems are not created yet. Is that right?

Actually I didn't think about such case, but yes handle_cli_req guarded by mutex (or recursive mutex for some reason...) in handle_cli_req_prelock: https://github.com/ClickHouse-Extras/NuRaft/blob/1707a7572aa66ec5d0a2dbe2bf5effa3352e6b2d/src/handle_client_request.cxx#L40-L53.

BTW I cannot catch "thread inversion" even under heavy load. But according to the code it should be possible.

Thanks, let me merge it.