VALKEY-COMMAND-TIPS(7)

💖 VALKEY-COMMAND-TIPS(7) 💖

okay bestie, welcome to the glow-up guide for valkey-command-tips — the page that explains Command tips. yes it's a manual page, no it's not boring, come with me 🫶

---

✨ NAME ✨

valkey-command-tips — Command tips (yes that's the whole name, she's simple and she's iconic)

---

🌸 DESCRIPTION 🌸

so this page documents a small part of the reply of command(3valkey). Like, a lil slice. A garnish. 🍓

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. that's her. that's the girl.

These tips give Valkey clients extra info about the command. The info can tell Valkey Cluster clients how the command should be executed and how its output should be processed in a clustered deployment. basically: cluster client instructions, no cap.

Now — unlike the command's flags (that's the 3rd element of command(3valkey)'s reply), which are strictly internal to the server's operation, tips don't serve any purpose other than being reported to clients. so if you're like "why do these exist", it's literally just to be handed to the client. that's it. she's a messenger 💅

---

🎲 nondeterministic_output

This tip says: the command's output isn't deterministic. Which means calls to the command may yield different results even with the same arguments and data. 😭

That difference could come from:

• 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). so the vibes are consistent but the lineup is shuffled. main character energy, no fixed seating chart ✨

Note: Prior to Redis OSS 7.0, this tip was the sort_for_script flag.

---

📮 request_policy:value

This tip can help clients figure out which shards to send the command to in clustering mode. 🗺️

The default behavior a client should implement for commands without the request_policy tip is as follows:

1. The command doesn't accept key name arguments: the client can execute the command on an arbitrary shard.
2. For commands that accept one or more key name arguments: the client should route the command to a single shard, as determined by the hash slot of the input keys.

In cases where the client should adopt a behavior different than the default, the request_policy tip can be one of:

• all_nodes — the client should execute the command on all nodes — primaries and replicas alike. An example is the CONFIG SET command. This tip is in-use by commands that don't accept key name arguments. The command operates atomically per shard.
• all_shards — the client should execute the command on all primary shards (e.g., the DBSIZE command). This tip is in-use by commands that don't accept key name arguments. The command operates atomically per shard.
• multi_shard — the client should execute the command on several shards. The client should split the inputs according to the hash slots of its input key name arguments. For example, the command 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.
• special — indicates a non-trivial form of the client's request policy, such as the SCAN command.

---

🧮 response_policy:value

This 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:

1. The command doesn't accept key name arguments: the client can aggregate all replies within a single nested data structure. For example, the array replies we get from calling KEYS against all shards. These should be packed in a single in no particular order.
2. For commands that accept one or more key name arguments: the client needs to retain the same order of replies as the input key names. For example, 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:

• one_succeeded — the clients should return success if at least one shard didn't reply with an error. The client should reply with the first non-error reply it obtains. If all shards return an error, the client can reply with any one of these. For example, consider a 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.
• all_succeeded — the client should return successfully only if there are no error replies. Even a single error reply should disqualify the aggregate and be returned. Otherwise, the client should return one of the non-error replies. As an example, consider the CONFIG SET, SCRIPT FLUSH and SCRIPT LOAD commands.
• agg_logical_and — the client should return the result of a logical AND operation on all replies (only applies to integer replies, usually from commands that return either 0 or 1). Consider the 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.
• agg_logical_or — the client should return the result of a logical AND operation on all replies (only applies to integer replies, usually from commands that return either 0 or 1). (yes bestie, the page says AND here. I'm just reporting what she said. 💀)
• agg_min — the client should return the minimal value from the replies (only applies to numerical replies). The aggregate reply from a cluster-wide WAIT command, for example, should be the minimal value (number of synchronized replicas) from all shards.
• agg_max — the client should return the maximal value from the replies (only applies to numerical replies).
• agg_sum — the client should return the sum of replies (only applies to numerical replies). Example: DBSIZE.
• special — this type of tip indicates a non-trivial form of reply policy. INFO is an excellent example of that.

---

🌈 Example

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)

---

and that's the whole page, you ate it, you devoured 💅✨

Valkey 9.0.0 🌸 2025-10-21 — mwah, love u, go read command(3valkey) next, iykyk 🦋🎀