This page documents a small part of the reply of the COMMAND
. In the reply of the
COMMAND command, each command is represented by an array. The 8th
element in this array is the command tips. It’s an array of strings.
These provide Valkey clients with additional information about the command. The information can instruct Valkey Cluster clients as to how the command should be executed and its output processed in a clustered deployment.
Unlike the command’s flags (see the 3rd element of COMMAND
’s reply), which are
strictly internal to the server’s operation, tips don’t serve any
purpose other than being reported to clients.
nondeterministic_output
This tip indicates that the command’s output isn’t deterministic.
That means that calls to the command may yield different results with
the same arguments and data. That difference could be the result of the
command’s random nature (e.g., RANDOMKEY
and
SPOP
); the call’s timing (e.g., TTL
); or
generic differences that relate to the server’s state (e.g.,
INFO
and CLIENT LIST
).
Note: Prior to Redis OSS 7.0, this tip was the
random
command flag.
nondeterministic_output_order
The existence of this tip indicates that the command’s output is
deterministic, but its ordering is random (e.g., HGETALL
and SMEMBERS
).
Note: Prior to Redis OSS 7.0, this tip was the
sort_for_script
flag.
request_policy:
valueThis tip can help clients determine the shards to send the command in
clustering mode. The default behavior a client should implement for
commands without the request_policy
tip is as follows:
In cases where the client should adopt a behavior different than the
default, the request_policy
tip can be one of:
CONFIG SET
command. This tip is in-use by commands that
don’t accept key name arguments. The command operates atomically per
shard.DBSIZE
command). This tip
is in-use by commands that don’t accept key name arguments. The command
operates atomically per shard.DEL {foo} {foo}1 bar
should be split to
DEL {foo} {foo}1
and DEL bar
. If the keys are
hashed to more than a single slot, the command must be split even if all
the slots are managed by the same shard. Examples for such commands
include MSET
, MGET
and DEL
.
However, note that SUNIONSTORE
isn’t considered as
multi_shard because all of its keys must belong to the same
hash slot.SCAN
command.response_policy:
valueThis tip can help clients determine the aggregate they need to
compute from the replies of multiple shards in a cluster. The default
behavior for commands without a request_policy
tip only
applies to replies with of nested types (i.e., an array, a set, or a
map). The client’s implementation for the default behavior should be as
follows:
KEYS
against
all shards. These should be packed in a single in no particular
order.MGET
’s aggregated reply.The response_policy
tip is set for commands that reply
with scalar data types, or when it’s expected that clients implement a
non-default aggregate. This tip can be one of:
SCRIPT KILL
command that’s sent to all shards. Although
the script should be loaded in all of the cluster’s shards, the
SCRIPT KILL
will typically run only on one at a given
time.CONFIG SET
, SCRIPT FLUSH
and
SCRIPT LOAD
commands.SCRIPT EXISTS
command as an
example. It returns an array of 0’s and 1’s that
denote the existence of its given SHA1 sums in the script cache. The
aggregated response should be 1 only when all shards had
reported that a given script SHA1 sum is in their respective cache.WAIT
command, for example, should
be the minimal value (number of synchronized replicas) from all
shards.DBSIZE
.INFO
is an excellent example of
that.127.0.0.1:6379> command info ping
1) 1) "ping"
2) (integer) -1
3) 1) fast
4) (integer) 0
5) (integer) 0
6) (integer) 0
7) 1) @fast
2) @connection
8) 1) "request_policy:all_shards"
2) "response_policy:all_succeeded"
9) (empty array)
10) (empty array)