yep - part of our fix was ordering the expires such that the invariants are maintained even if the expires arn't exactly at the same time (we are assuming expires are at least ordered)
yep - as i mentioned in a comment below - we arn't concerned about when the key is actually deleted - only that its not returned when looked up if its TTL is hit
I’m not aware of the docs making any guarantees that expires are ordered either, just that at some point after the expiry time the keys will be expired.
sorry i should have explained. by ordered i meant after expiring a key its TTL will be set, which will never be a time before a previous expire. when it looks up the key, if its TTL has been reached it will not be returned (which we checked in the redis source). we weren't concerned about then the keys are actually removed
I'm pretty sure they aren't ordered. Redis active key expiry is a random process: https://redis.io/commands/expire#how-redis-expires-keys. TL;DR: Redis will randomly sample the keyspace and delete any expired keys it finds in the sample. If a large enough percentage of the sample was expired, it will repeat the process. Since the sample is random, it cannot be ordered.
There is also a "passive" key expiry where any read to a key will check the expiry time and delete the key if the current time is larger than the expiry time.
One hack I can think of is, accessing the keys. If the key is expired, then Redis won't provide it and you could know it is expired.
Another way is to club all of the relative keys in a hash [1]
[0] - https://redis.io/commands/expire#how-redis-expires-keys
[1] - https://redis.io/commands/hset