[insaf021]

With a PrefixedKeyArgumentPreProcessor("tenantA:") installed:

zunionstore : [ZUNIONSTORE, tenantA:dst, 1, tenantA:src]
zrangestore : [ZRANGESTORE, tenantA:dst, src, 0, -1]
eval (List) : [EVAL, return 1, 1, tenantA:k, v]
eval (varar): [EVAL, return 1, 1, k, v]

CommandArguments.key(Object) is the only place the pre-processor runs and the only place a key is recorded for slot computation, so a key routed through add() reaches the wire untransformed and never enters getKeys(). ZRANGESTORE then writes inside the namespace and reads from outside it, and the cluster provider sees one slot for a two key command so its multi slot guard cannot fire.

Eighteen sites, all the same shape: the source key of zrangestore and geosearchStore/geosearchStoreStoreDist, and the first keyCount varargs of eval/evalsha. The eval varargs overloads already called addHashSlotKeys, which records the slot but leaves the outgoing argument alone; the List<String> keys overloads beside them were always correct and are untouched.

Without a pre-processor, the eval/evalsha varargs overloads behave exactly as before — their slot keys were already registered via addHashSlotKeys, so this PR only changes which argument value goes out when a pre-processor rewrites keys.

For ZRANGESTORE and GEOSEARCHSTORE there is one behaviour change even without a pre-processor: the source key now enters getKeys(), so on cluster a cross-slot call fails client-side with JedisClusterOperationException instead of being dispatched to the destination's node and rejected by the server with a CROSSSLOT error. Standalone behaviour is unchanged.

Tests: cluster tests assert the cross-slot rejection for every zrangestore/geosearchStore overload and pin eval/evalsha varargs slot registration.

Closes #4674

---

Note

Medium Risk
Fixes cluster slot tracking and key preprocessing for multi-key commands; behavior is unchanged without a key preprocessor, but cluster routing and prefixed keys now correctly include source keys.

Overview
Fixes source keys bypassing key() registration in zrangestore, geosearchStore/geosearchStoreStoreDist, and eval/evalsha varargs overloads.

Those keys were previously passed with add(), so they skipped key preprocessors and were omitted from cluster slot computation. They now go through key(), matching commands like zunionstore. The eval/evalsha varargs paths also stop using addHashSlotKeys alone (which recorded slots but left wire args untransformed).

Cluster tests assert cross-slot rejection for the fixed commands. Without a key preprocessor, wire behavior is unchanged.

^{Reviewed by Cursor Bugbot for commit 2a37c60. Bugbot is set up for automated code reviews on this repo. Configure here.}

[ggivo]

Thanks for the PR, @insaf021.

Team capacity is limited so PR reviews can take some time. There's a corresponding issue (#4674) that still needs triage and acceptance by the team before the PR proposal can be considered.

[insaf021]

Understood, no rush. I've answered the usage question over on #4674. Also rebased onto master to pick up the redis:8.6.2 pin from #4676, so the unrelated SDR failure on the previous run should clear.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 550dc4bd20

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".