Questions GetCommitVersionRequest request number necessity

As I read the source code of, it seems that the logic of get commit version is like

wait(self->latestLocalCommitBatchResolving.whenAtLeast(localBatchNumber - 1));
some codes
send the commit version request
wait for commit version reply
send resolving requests
update latestLocalCommitBatchResolving to localBatchNumber asynchronously
wait for resolving replies

So it seems to my for each proxy, there can be at most one get commit version request on the fly, as all the othe ones are queued by latestLocalCommitBatchResolving, so why is request number still necessary? I really don’t get it.

Because we’re sending this request at least once… Basically, if you call send or getReply on a RequestStream<T> we’re in fact calling sendReliable. So if the connection to the master/sequencer is closed after we sent the request but before we received a response, we will automatically retry (send this request again).

So the sequencer might get both (we don’t know whether the first one was lost or not). Giving out two versions would cause problems (specifically, we would now create a hole in the version stream and at the resolve-step the resolver would block all transaction waiting for this hole to be filled). You can find the code that handles this in the master here.

1 Like