However, if I include versionstamps whose version is equal to the current read version, I’m back to “read or wrote an unreadable key”.
Looking into this more, I believe this to be a bug.
In the developer guide under How Versions are Generated and Assigned, it states that:
- The read version is equal to “the last committed version as of the time it received the request”.
- On commit, “the commit proxy will ask for a new version from the master”
- “FoundationDB guarantees that no version will be generated twice and that the versions are monotonically increasing.”
Since the read version is an existing version and the commit version is a new version, it follows that the commit version must always be strictly greater than the read version.
However, the FDB client includes the read version as part of the range marked as unreadable when setting a versionstamped key: https://github.com/apple/foundationdb/blob/d47a2ab60fe145da8a779a9c6812dca0cc3aad39/fdbclient/ReadYourWrites.actor.cpp#L2195-L2201
Since the read version is the last committed version, it means this range overlaps with versionstamps added in the previous transaction, preventing you from reading them.
I think if the code that calls getVersionstampKeyRange (or that function itself) were updated to add 1 to the read version, it would solve this.