Skip to content

Pass zrank/zrevrank keys so they are cacheable (fixes ValueError under CSC) - #4249

Open
uttam12331 wants to merge 1 commit into
redis:masterfrom
uttam12331:fix-zrank-zrevrank-cache-keys
Open

Pass zrank/zrevrank keys so they are cacheable (fixes ValueError under CSC)#4249
uttam12331 wants to merge 1 commit into
redis:masterfrom
uttam12331:fix-zrank-zrevrank-cache-keys

Conversation

@uttam12331

@uttam12331 uttam12331 commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Summary

ZRANK and ZREVRANK are in the client-side cache allow list (redis/cache.py), but neither sets options["keys"]. When client-side caching is enabled, building the cache key raises:

ValueError: Cannot create cache key.

(from redis/connection.py, if kwargs.get("keys") is None: raise ValueError("Cannot create cache key.")), so these two commands can't be used with caching at all.

This was pointed out by @petyaslavova in #4244:

ZRANK and ZREVRANK are in the cache allow list but pass no keys at all, so they currently will raise ValueError("Cannot create cache key.") when client-side caching is enabled.

Fix

Set options["keys"] = [name] in both zrank and zrevrank, matching the range commands:

         options = {"withscore": withscore, "score_cast_func": score_cast_func}
+        options["keys"] = [name]

         return self.execute_command(*pieces, **options)

Tests

Added test_zrank_zrevrank_are_cacheable (in tests/test_cache.py), which caches zrank/zrevrank (no ValueError), asserts the entries are stored under redis_keys=("myzset",), and that mutating the sorted set from a second client invalidates them.


Note

Low Risk
Small, pattern-aligned change to command options plus cache tests; no auth, security, or data-model impact.

Overview
Fixes client-side caching for ZRANK and ZREVRANK. Those commands were on the cache allow list but did not pass options["keys"], so execute_command raised ValueError: Cannot create cache key. whenever CSC was enabled.

Both zrank and zrevrank now set options["keys"] = [name], consistent with other sorted-set read helpers (e.g. zrange). Cache entries are keyed on the sorted-set name and invalidate when that key changes.

A new cache test confirms ranks can be cached without error, entries appear under redis_keys=("myzset",), and a zadd from a second client refreshes stale ranks.

Reviewed by Cursor Bugbot for commit 4d16982. Bugbot is set up for automated code reviews on this repo. Configure here.

ZRANK and ZREVRANK are in the client-side cache allow list, but neither set
options["keys"], so building the cache key raised
ValueError("Cannot create cache key.") whenever caching was enabled.

Set options["keys"] = [name] for both, matching the range commands, and add
a regression test that caches zrank/zrevrank and checks invalidation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant