The problem

Reading the documentation:

https://redis.io/commands/command#movable-keys
https://redis.io/commands/command-getkeys

There is no way today to cache key indexes for commands such as ZUNIONSTORE/EVAL others with "numkeys", since COMMAND INFO returns 0 info for them.

This requires to 'patch' the code for those commands, or to disable caching and resolve each such command's keys with COMMAND GETKEYS if you are planning on a cluster aware redis client.

The solution

All commands that have "numkeys" indexing (most / all of movable keys), should instead of this output:

127.0.0.1:6379> command info eval
1) 1) "eval"
   2) (integer) -3
   3) 1) noscript
      2) movablekeys
   4) (integer) 0
   5) (integer) 0
   6) (integer) 0
   7) 1) @slow
      2) @scripting

Produce this output:

127.0.0.1:6379> command info eval
1) 1) "eval"
   2) (integer) -3
   3) 1) noscript
      2) movablekeys
   4) (integer) 3
   5) (integer) -2
   6) (integer) 1
   7) 1) @slow
      2) @scripting

The main change here is that argument #5 (Last key in argument list) meaning under "movablekeys" is different:

https://redis.io/commands/command#last-key-in-argument-list

It's negative so that people who ignore reading the documentation, will not use it by accident, and it absolute value points to index which holds the numkeys.

Also it's non-conflicting with -1 meaning in the regular case, because numkeys means it's not infinite number of keys, just that index 1 holds how many keys there are.

This will make the clients be able to cache this information for cluster key usage.

Ofcourse a breaking change (such as ACL did) to the output can just add another variable that means (-1 no such numkeys index, or for the numkeys index) instead.