The sled storage backend has two bugs:
1. del() writes the wrong marker byte
In sled.rs, the del() method writes PUT_MARKER (1) instead of DEL_MARKER (0) into the changes buffer. This means deletes within a transaction are silently treated as puts with empty values. The key is never actually removed on commit.
2. range_skip_scan_tuple() is unimplemented
The method returns iter::once(Err(...)), making time travel queries fail on the sled backend. The same validity-checking pattern used by the memory and RocksDB backends (via check_key_for_validity and seeking) works with sled's range API.
I have a fix for both, with tests that demonstrate the del bug (fails without the fix) and exercise time travel with multiple keys and timestamps. Happy to open a PR if there's interest.
The sled storage backend has two bugs:
1.
del()writes the wrong marker byteIn
sled.rs, thedel()method writesPUT_MARKER(1) instead ofDEL_MARKER(0) into the changes buffer. This means deletes within a transaction are silently treated as puts with empty values. The key is never actually removed on commit.2.
range_skip_scan_tuple()is unimplementedThe method returns
iter::once(Err(...)), making time travel queries fail on the sled backend. The same validity-checking pattern used by the memory and RocksDB backends (viacheck_key_for_validityand seeking) works with sled's range API.I have a fix for both, with tests that demonstrate the del bug (fails without the fix) and exercise time travel with multiple keys and timestamps. Happy to open a PR if there's interest.