As I was working on binding tester, I noticed that C API fdb_future_get_int64 that is used to resolve the futures returned by
fdb_transaction_get_read_versionfdb_transaction_get_estimated_range_size_bytesfdb_transaction_get_approximate_sizereturns a int64. I was wondering if there was some reason to return a int64 instead of a uint64 for these APIs? I should have noticed this before, but somehow missed it. 
I had previously assumed GRV was a cluster-wide 64 bit positive counter.
The Version type within FDB is defined as int64_t, see here. That’s why int64 is chosen.
I see. So, if we are going to rely on GRV to infer happens before relation between two transactions, then its our (caller’s) responsibility to transmute the int64 to uint64.
Would this be a correct assumption?
Yes, the caller has to do that. However, I want to point out that the GRV that the caller gets should always be positive numbers. Negative version number only exists internally for initializations of some version numbers.
BTW, GRV only implies happen-before for read-only transactions. For read-write transactions, they happen at the commit version, which should be used to reason about happen-before relationship.
Thanks @jzhou for the reply!