In general, I think a good rule of thumb is that if it is a blocking call, then it doesn’t take a long time (and almost certainly doesn’t make any network calls).
In particular, the reason that (except for commit) writes are synchronous calls is that the call only has to update an in-memory buffer. In particular, all mutations to the database only update a local cache known as the “write cache” that is then only sent to the cluster at commit time.
getReadVersion request sometimes requires a network call. In particular, if there haven’t been any reads done within a transaction, then the client has to communicate with the cluster to get a version, hence it returns a future. (Note that if the transaction already has a read version, then the call to
getReadVersion is actually very fast as it only has to read the already cached value from memory.)
The two calls,
getVersionstamp, are very similar, but they have slightly different semantics. Both the commit version and the versionstamp for a transaction are determined by the cluster as part of the commit process, so after a
commit completes, it should be cheap to get that value as the cluster can return that information to the client. That is exactly why
getCommittedVersion is synchronous–namely, that it just requires looking up the value, not doing any I/O. In theory,
getVersionstamp could be similar (and instead by synchronous and just look up the value from an already committed transaction), but instead, it allows for the user to return a future that will complete at essentially the same time as
commit, which theoretically could be useful (and allows the user to, for example, return a future from the
FDBDatabase.run retry loop that is essentially guaranteed to be complete when the commit ends–something that
getCommittedVersion makes essentially impossible because it calls commit for you in a place you can’t control). In principle, both of these calls could have been structured to work the same way, but instead, one was implemented one way and one the other.