Hi,

I am currently working on implementing the request and response policies in node-redis, and I have encountered some issues with the multi_shard request policy:

  1. The policy name should be changed from multi_shard to multi_slot, as even if two slots belong to the same shard, it will result in CROSSSLOT error. For example, MSET a a b b is invalid even if slots 15495 and 3300 (which correspond to "a" and "b") are in the same shard.
  2. Simple write commands like MSET and DEL are no longer atomic when used with multi_slot.
  3. With MSETNX, the NX option is applied per slot.
  4. Any STORE command does not work with multi_slot, as all keys must be from the same slot as the destination key.

In my opinion, it might be better to mark these commands as special, and provide a helper function on the cluster (client-side) that can split an array of keys per slot. This approach would make it clear to the user that it is not a single command, and it would allow the user to choose what to do in error cases.

Comment From: Stuti-Ajmera

Hi @leibale changing the policy name from multi_shard to multi_slot sounds resonable. Also I believe we already have an command CLUSTER GETKEYSINSLOT , which returns an array of keys names stored in the contacted node and hashing to the specified hash slot. Can you provide more details on what exactly is the use case and what are you expecting.

Comment From: leibale

@Stuti-Ajmera the function I suggested at the end is for the clients to implement. I've edited my original comment to make it clearer.