Redis Missing routing tips - Nineya|java/go/python

How is PUBSUB SHARDCHANNELS supposed to be routed & aggregated in cluster mode? The command doesn't have any keys, and a pattern isn't hashed in a similar manner to the channels matching the pattern. Should the commands just be sent to all nodes?

I assume that PUBSUB NUMSUB | NUMPAT are missing routing tips for cluster mode. Considering that shards may have both sharded and unsharded channels, the sum of subscriptions isn't simple to calculate across shards, since some subscriptions may be shared.

Comment From: barshaul

Additionally, all of the CLIENT commands don't have request/response policy. Some suggestions:

CLIENT CACHING (all_nodes, all_succeeded?)
CLIENT GETNAME - (should be the same as CONFIG GET, with a random_node?)
CLIENT GETREDIR (all_nodes, all_succeeded?)
CLIENT ID (all_nodes/random_node?)
CLIENT INFO (all_nodes, special- as in info?)
CLIENT KILL - (all_nodes, special- as in info?)
CLIENT LIST - (all_nodes, all_succeeded?)
CLIENT NO-EVICT (all_nodes, all_succeeded?)
CLIENT NO-TOUCH (all_nodes, all_succeeded?)
CLIENT PAUSE (all_nodes, all_succeeded?)
CLIENT REPLY (all_nodes, all_succeeded?)
CLIENT SETINFO (all_nodes, all_succeeded?)
CLIENT SETNAME - (should be the same as CONFIG SET, with all_nodes, all_succeeded?)
CLIENT TRACKING (there isn't a good option - so - random_node?)
CLIENT TRACKINGINFO (all_nodes, all_succeeded?)
CLIENT UNBLOCK (all_nodes, all_succeeded?)
CLIENT UNPAUSE (all_nodes, all_succeeded?)

Comment From: oranagra

first, just to set the right background, these tips are limited. for many commands they're able to reduce the need of the client library or proxy to maintain an explicit code that handles each command separately, and instead they divide them to categories. the main benefit for that is that when a new command is added, or a module is loaded, these new commands can implicitly be handled correctly without the need of the client / proxy maintainer to add code to handle them (turn module commands to be more of a first class citizens).

but this only goes so far... there are commands for which we can't provide any or useful tips, and for these, the client library may have to add explicit code to handle them correctly. i.e. some commands such as SCAN, INFO and others are marked with either request_policy or response_policy of SPECIAL, and it's up to the caller to figure out how to handle them and write explicit code for that.

since these tips are still work in progress, it could be that there are bugs and gaps to fix. but i think all the ones you asked about above fall in the SPECIAL category.

the PUBSUB is probably similar to INFO, feel free to make a PR.

the the CLIENT ones are more of an administrative commands, and how they're handled greatly depends on the implementation of the proxy or client. for many of them, just blinding broadcasting them to all cluster nodes is probably wrong.