@amorton yes, my apologies. It is not specified well.

the format is indeed "text~long" ... where text can include any character including tilde and numbers. I believe the ~long is also optional.

So, the algo for tokenization of the key is to find the last tilde in the string. If everything after it is a digit, treat it as a long (these are timestamps). If there is no tilde, or the chars after the last tilde are not all digits, treat the entire key as the text (this is the document id)

So, for the comparator, you have a key with two optional parts: a document id and a timestamp.

Comparison of the timestamp takes presidence, followed by comparison of the document id.

The timestamp is always sorted in descending order.

The document id should be sorted in alphanumeric order. However, this seems further complicated by the implementation in production which, I believe, sorts the document id in reverse order in some cases.

In any event, I've added 3 test cases to master that pass on the comparator in production but fail on this proposed comparator. For better or worse, the new comparator needs to sort the same as the old.