A reversed range
The higher bound comes first, which is what REV requires
- key
- leaderboard
- by
- score
- min
- 100
- max
- 500
- reverse
- yes
Build a ZRANGE. The bug this exists to prevent: with REV, the higher bound comes first. Writing the arguments in the order you say them out loud returns an empty result with no error at all.
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
The higher bound comes first, which is what REV requires
A combination Redis rejects, because index ranges already take start and stop
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
REV expects the higher bound first. The other order describes an empty range and returns nothing, with no error.
Instead:Put the high bound first when using REV.
LIMIT is not valid with an index range.
Instead:Use BYSCORE with LIMIT offset count.
Lexicographic order only holds when every member shares a score. Otherwise the result is not alphabetical.
Instead:Use a single score, conventionally 0, or use BYSCORE.
Bounds are inclusive by default, so the range quietly includes one extra element.
Instead:Keep ( attached to the value.
Redis 6.2 merged six commands into ZRANGE. The options are clearer than the old names, and two of them interact in ways that fail silently.
Without REV you give the low bound then the high one. With REV you give the HIGH bound then the low one. Getting it the wrong way round is not an error: it describes an empty range, so Redis returns nothing and nothing explains why. This is the most common ZRANGE bug there is.
An index range already takes a start and a stop, so an offset and count would be meaningless and Redis rejects the combination. For score ranges LIMIT is how pagination works, and it is the reason to prefer BYSCORE over index ranges for paging.
Lexicographic ordering assumes the set is ordered by member. If scores differ, the ordering is by score first, and the result is not the alphabetical range it appears to be. Nothing warns about this, because it is a valid query over a set that happens to be shaped differently than assumed.
Bounds are inclusive by default and the parenthesis is the only way to exclude an endpoint. It is easy to lose when a bound is built by string concatenation, and losing it produces an off-by-one that is invisible in the query.
ZRANGEBYSCORE, ZREVRANGE and the rest are soft-deprecated rather than removed. On a server older than 6.2 they are the only option, because ZRANGE there does not accept BYSCORE, BYLEX or REV.