{
  "id": "command-tips",
  "title": "Redis command tips",
  "url": "https://un5pn9hmggug.julianrbryant.com/docs/latest/develop/reference/command-tips/",
  "summary": "Get additional information about a command",
  "tags": [
    "docs",
    "develop",
    "stack",
    "oss",
    "rs",
    "rc",
    "oss",
    "kubernetes",
    "clients"
  ],
  "last_updated": "2026-04-01T08:10:08-05:00",
  "page_type": "content",
  "content_hash": "8a717af358882425e37f158e9028f6ec7a14e341b8d50e1915bceb189700eba3",
  "sections": [
    {
      "id": "overview",
      "title": "Overview",
      "role": "overview",
      "text": "Command tips are an array of strings.\nThese provide Redis clients with additional information about the command.\nThe information can instruct Redis Cluster clients as to how the command should be executed and its output processed in a clustered deployment.\n\nUnlike 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.\n\nCommand tips are arbitrary strings.\nHowever, the following sections describe proposed tips and demonstrate the conventions they are likely to adhere to."
    },
    {
      "id": "nondeterministic-output",
      "title": "nondeterministic_output",
      "role": "content",
      "text": "This tip indicates that the command's output isn't deterministic.\nThat means that calls to the command may yield different results with the same arguments and data.\nThat 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`]()).\n\n**Note:**\nPrior to Redis 7.0, this tip was the _random_ command flag."
    },
    {
      "id": "nondeterministic-output-order",
      "title": "nondeterministic_output_order",
      "role": "content",
      "text": "The existence of this tip indicates that the command's output is deterministic, but its ordering is random (e.g., [`HGETALL`]() and [`SMEMBERS`]()).\n\n**Note:**\nPrior to Redis 7.0, this tip was the _sort_\\__for_\\__script_ flag."
    },
    {
      "id": "request-policy",
      "title": "request_policy",
      "role": "content",
      "text": "This tip can help clients determine the shards to send the command in clustering mode.\nThe default behavior a client should implement for commands without the _request_policy_ tip is as follows:\n\n1. The command doesn't accept key name arguments: the client can execute the command on an arbitrary shard.\n1. 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.\n\nIn cases where the client should adopt a behavior different than the default, the _request_policy_ tip can be one of:\n\n- **all_nodes:** the client should execute the command on all nodes - masters and replicas alike.\n  An example is the [`CONFIG SET`]() command. \n  This tip is in-use by commands that don't accept key name arguments.\n  The command operates atomically per shard.\n* **all_shards:** the client should execute the command on all master shards (e.g., the [`DBSIZE`]() command).\n  This tip is in-use by commands that don't accept key name arguments.\n  The command operates atomically per shard.\n- **multi_shard:** the client should execute the command on several shards.\n  The client should split the inputs according to the hash slots of its input key name arguments.\n  For example, the command `DEL {foo} {foo}1 bar` should be split to `DEL {foo} {foo}1` and `DEL bar`.\n  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.\n  Examples for such commands include [`MSET`](), [`MGET`]() and [`DEL`]().\n  However, note that [`SUNIONSTORE`]() isn't considered as _multi_shard_ because all of its keys must belong to the same hash slot.\n- **special:** indicates a non-trivial form of the client's request policy, such as the [`SCAN`]() command."
    },
    {
      "id": "response-policy",
      "title": "response_policy",
      "role": "returns",
      "text": "This tip can help clients determine the aggregate they need to compute from the replies of multiple shards in a cluster.\nThe 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).\nThe client's implementation for the default behavior should be as follows:\n\n1. The command doesn't accept key name arguments: the client can aggregate all replies within a single nested data structure.\nFor example, the array replies we get from calling [`KEYS`]() against all shards.\nThese should be packed in a single in no particular order.\n1. 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.\nFor example, [`MGET`]()'s aggregated reply.\n\nThe _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.\nThis tip can be one of:\n\n* **one_succeeded:** the clients should return success if at least one shard didn't reply with an error.\n  The client should reply with the first non-error reply it obtains.\n  If all shards return an error, the client can reply with any one of these.\n  For example, consider a [`SCRIPT KILL`]() command that's sent to all shards.\n  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.\n* **all_succeeded:** the client should return successfully only if there are no error replies.\n  Even a single error reply should disqualify the aggregate and be returned.\n  Otherwise, the client should return one of the non-error replies.\n  As an example, consider the [`CONFIG SET`](), [`SCRIPT FLUSH`]() and [`SCRIPT LOAD`]() commands.\n* **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_).\n  Consider the [`SCRIPT EXISTS`]() command as an example.\n  It returns an array of _0_'s and _1_'s that denote the existence of its given SHA1 sums in the script cache.\n  The aggregated response should be _1_ only when all shards had reported that a given script SHA1 sum is in their respective cache.\n* **agg_logical_or:** the client should return the result of a logical _OR_ operation on all replies (only applies to integer replies, usually from commands that return either _0_ or _1_).\n* **agg_min:** the client should return the minimal value from the replies (only applies to numerical replies).\n  The aggregate reply from a cluster-wide [`WAIT`]() command, for example, should be the minimal value (number of synchronized replicas) from all shards.\n* **agg_max:** the client should return the maximal value from the replies (only applies to numerical replies).\n* **agg_sum:** the client should return the sum of replies (only applies to numerical replies).\n  Example: [`DBSIZE`]().\n* **special:** this type of tip indicates a non-trivial form of reply policy.\n  [`INFO`]() is an excellent example of that."
    },
    {
      "id": "example",
      "title": "Example",
      "role": "example",
      "text": "[code example]"
    }
  ],
  "examples": [
    {
      "id": "example-ex0",
      "language": "plaintext",
      "code": "redis> command info ping\n1)  1) \"ping\"\n    2) (integer) -1\n    3) 1) fast\n    4) (integer) 0\n    5) (integer) 0\n    6) (integer) 0\n    7) 1) @fast\n       2) @connection\n    8) 1) \"request_policy:all_shards\"\n       2) \"response_policy:all_succeeded\"\n    9) (empty array)\n   10) (empty array)",
      "section_id": "example"
    }
  ]
}