I would like to duplicate etcd's watch-stream functionality in a Rust application which uses RocksDB. According to etcd's documentation:
Watches make three guarantees about events:
Ordered - events are ordered by revision; an event will never appear on a watch if it precedes an event in time that has already been posted.
Reliable - a sequence of events will never drop any subsequence of events; if there are events ordered in time as a < b < c, then if the watch receives events a and c, it is guaranteed to receive b.
Atomic - a list of events is guaranteed to encompass complete revisions; updates in the same revision over multiple keys will not be split over several lists of events.
One approach I've considered is to combine latest_sequence_number with get_updates_since, but that requires me to deserialize the WriteBatch, and it's not guaranteed to work properly. For example, if the size of get_updates_since is zero, it could be because there have not been any updates to the key space, or it could be that a compaction has occurred. There does not seem to be a way to differentiate between those two states. In other words, I have no basis upon which I can return an error saying, "The provided sequence number is too old and has already been compacted".
I've also looked at tailing iterators, but the documentation states:
Not all new data is guaranteed to be available to a tailing iterator.
Kubernetes provides this functionality by exposing etcd's mod_revision to clients. Is there such an equivalent in RocksDB?