CompareWithoutTimestamp key has timestamp when hasTS is false

[muthukrishnan24]

Expected behavior

in CompareWithoutTimestamp call, when hasTS is false, key should not have timestamp part

Actual behavior

in CompareWithoutTimestamp call, when hasTS is false, key has both user key and timestamp

Steps to reproduce the behavior

• open db with timestamp enabled for default cf
• create a WriteBatchWithIndex with backup comparator same as default cf
• put two key-value

args has given key (foo) and dummy ts (all zero) but hasTs is false

example:

• wbwi.Put(handle, "foo", "val")
• wbwi.Put(handle, "bar", "val")

args got in CompareWithoutTimestamp calls

KeyA: foo, aHasTS: 0, aLen 11 ; KeyB: bar, bHasTS: 0, bLen 3
KeyA: bar, aHasTS: 0, aLen 3 ; KeyB: foo, bHasTS: 0, bLen 3
KeyA: foo, aHasTS: 0, aLen 11 ; KeyB: bar, bHasTS: 0, bLen 11
KeyA: foo, aHasTS: 0, aLen 11 ; KeyB: bar, bHasTS: 0, bLen 11
KeyA: bar, aHasTS: 0, aLen 11 ; KeyB: foo, bHasTS: 0, bLen 11

@riversand963

[riversand963]

Thanks @muthukrishnan24. I think it's due to https://github.com/facebook/rocksdb/blob/7.7.fb/utilities/write_batch_with_index/write_batch_with_index.cc#L150. The key size is the length encoded in the write batch, thus is key + ts_sz. Should not be hard to fix. Fortunately, this does not trigger an assertion failure. Furthermore, before you assign a timestamp to the write batch, they all remain 0. If you assign timestamp after you are done with reading/writing the batch, and then write to db, the result should still be correct.