Hello,

thanks for you work. I'm posting this issue/question mainly in order to check if my understanding of the intended design of the underlying raft library is correct.

In the __http_get_id() entry point that serves a client request for a new unique ID, I see a potential race: __http_get_id() invokes __generate_ticket() which in turn checks that the random ID it generates does not exists already by querying the LMDB database. However, it seems there is a possible delay between the time the server finishes the client HTTP request, handing it the newly generated ID, and the time it actually commits that ID into the LMDB database.

My reading is that at the time the __http_get_id() handler calls e = raft_msg_entry_response_committed(sv->raft, &r), the newly generated ID might not be yet committed in LMDB database, because applying new log entries to the FSM happens "lazily" within the raft library. See the relevant comment in the raft_recv_appendentries_response function. In particular, this would mean that if a new client request is served by __http_get_id() before the libuv timer invokes raft_periodic applying the entry to the FSM, then __generate_ticket() could generate the same ID again but not see it committed in the LMDB database, hence leading to a duplicate ID.

Does that make sense?