[c0l0]

I don't want to sound snarky, but since you mentioned that Redis does not document if/that "multiple key expiry is guaranteed to occur at the same time if keys have the same EXPIREAT setting", I am tempted to ask - why did you not check the implementation you're using? That's the unique selling point of using FOSS - you don't have rely on documentation or observational guesswork - you can wade in and really see for yourself! Redis' source code is especially readable in my opinion (thanks again, antirez, for creating this little load-bearing gem of a data structure server), so I would very much encourage you to try, even if C is not your particular forte :)

[staticassertion]

Not who you're asking but... why have documentation at all? So that we don't have to read source code.

[c0l0]

Because documentation is what is needs to be: A simplified and necessarily incomplete description of program behavior. It's a trade-off, since a complete and exhaustive description of all intricacies of potential program behavior would be at least as complex as the definition (= its source code) of said program.

If you happen to have a question that ends up on the wrong side of that trade-off between documentation's completeness and accessibility, you will have to descend into the depths that lie beneath. I believe the redis documentation actually strikes a rather OK balance in that regard.

[staticassertion]

Good docs generally make guarantees and pitfalls clear.

[scraptor]

Of course having documentation is better but that's not a reason not to read the source code if the documentation isn't enough.

[voidfunc]

Because good docs are like a good search engine: high hit rate for what you want most of the time.

The edge cases and quirky impl detail questions are what src is for.

[megapolitics]

I would argue that outlining expected behaviour in edge cases is one of the most important topics for documentation to cover.

[staticassertion]

> The edge cases and quirky impl detail questions are what src is for.

Literally the most important thing you can document.

[edf13]

You can’t cover every usage possibility in docs… having the code available allows you to check expected behaviour

[rileymat2]

You also can’t tell what is supported behavior and what is implementation coincidence from the code…

[macspoofing]

That's a great suggestion, and OP should do this, but even if OP verifies behaviour today through code inspection, it's possible a future release could change it. The problem is that Redis doesn't want to make that guarantee so you can't rely on it.

[andydunstall]

yep good point :) - in the end it didnt matter much as we could maintain our invariants if we just reordered the expires