Add hyperlinks for referenced commands to cluster and client connect command files

commands/auth.md

@@ -5,7 +5,7 @@ The standard way to `AUTH` is the two-argument form:
     AUTH <username> <password>
 
 This authenticates the current connection with one of the users
-defined in the ACL list (see `ACL SETUSER` and the official [ACL guide](../topics/acl.md) for more information).
+defined in the ACL list (see [`ACL SETUSER`](acl-setuser.md) and the official [ACL guide](../topics/acl.md) for more information).
 
 When the single argument form of the command is used, where only the password is specified,
 it is assumed that the implicit username is "default".
@@ -22,4 +22,4 @@ Otherwise, an error is returned and the clients needs to try a new password.
 Because of the high performance nature of Valkey, it is possible to try
 a lot of passwords in parallel in very short time, so make sure to generate a
 strong and very long password so that this attack is infeasible.
-A good way to generate strong passwords is via the `ACL GENPASS` command.
+A good way to generate strong passwords is via the [`ACL GENPASS`](acl-genpass.md) command.

commands/client-caching.md

@@ -4,7 +4,7 @@ Please check the
 [client side caching documentation](../topics/client-side-caching.md) for
 background information.
 
-When tracking is enabled Valkey, using the `CLIENT TRACKING` command, it is
+When tracking is enabled Valkey, using the [`CLIENT TRACKING`](client-tracking.md) command, it is
 possible to specify the `OPTIN` or `OPTOUT` options, so that keys
 in read only commands are not automatically remembered by the server to
 be invalidated later. When we are in `OPTIN` mode, we can enable the

commands/client-capa.md

@@ -9,4 +9,4 @@ The capabilities currently supported are:
 * `redirect` - This indicates that the client is capable of handling redirect messages.
   When accessing a replica node in standalone mode, if a data operation is performed (read or write commands),
   Valkey will return `-REDIRECT primary-ip:port` to this connection.
-  Using the `READONLY` command can enable this connection to execute read commands on the replica node.
+  Using the [`READONLY`](readonly.md) command can enable this connection to execute read commands on the replica node.

commands/client-getname.md

@@ -1 +1 @@
-The `CLIENT GETNAME` returns the name of the current connection as set by `CLIENT SETNAME`. Since every new connection starts without an associated name, if no name was assigned a null bulk reply is returned.
+The `CLIENT GETNAME` returns the name of the current connection as set by [`CLIENT SETNAME`](client-setname.md). Since every new connection starts without an associated name, if no name was assigned a null bulk reply is returned.

commands/client-getredir.md

@@ -1,6 +1,6 @@
 This command returns the client ID we are redirecting our
 [tracking](../topics/client-side-caching.md) notifications to. We set a client
-to redirect to when using `CLIENT TRACKING` to enable tracking. However in
+to redirect to when using [`CLIENT TRACKING`](client-tracking.md) to enable tracking. However in
 order to avoid forcing client libraries implementations to remember the
 ID notifications are redirected to, this command exists in order to improve
 introspection and allow clients to check later if redirection is active

commands/client-id.md

@@ -4,7 +4,7 @@ ID has certain guarantees:
 1. It is never repeated, so if `CLIENT ID` returns the same number, the caller can be sure that the underlying client did not disconnect and reconnect the connection, but it is still the same connection.
 2. The ID is monotonically incremental. If the ID of a connection is greater than the ID of another connection, it is guaranteed that the second connection was established with the server at a later time.
 
-This command is especially useful together with `CLIENT UNBLOCK`.
+This command is especially useful together with [`CLIENT UNBLOCK`](client-unblock.md).
 Check the `CLIENT UNBLOCK` command page for a pattern involving the two commands.
 
 ## Examples

commands/client-info.md

@@ -1,6 +1,6 @@
 The command returns information and statistics about the current client connection in a mostly human readable format.
 
-The reply format is identical to that of `CLIENT LIST`, and the content consists only of information about the current client.
+The reply format is identical to that of [`CLIENT LIST`](client-list.md), and the content consists only of information about the current client.
 
 ## Examples
 

commands/client-list.md

@@ -45,7 +45,7 @@ Here is the meaning of the fields:
 * `addr`: address/port of the client
 * `laddr`: address/port of local address client connected to (bind address)
 * `fd`: file descriptor corresponding to the socket
-* `name`: the name set by the client with `CLIENT SETNAME`
+* `name`: the name set by the client with [`CLIENT SETNAME`](client-setname.md)
 * `age`: total duration of the connection in seconds
 * `idle`: idle time of the connection in seconds
 * `flags`: client flags (see below)
@@ -69,7 +69,7 @@ Here is the meaning of the fields:
 * `user`: the authenticated username of the client
 * `redir`: client id of current client tracking redirection
 * `resp`: client RESP protocol version.
-* `lib-name`: The client library name as set by `CLIENT SETINFO`
+* `lib-name`: The client library name as set by [`CLIENT SETINFO`](client-setinfo.md)
 * `lib-version`: The client library version as set by `CLIENT SETINFO`
 * `tot-net-in`: Total network input bytes read from this client. Added in Valkey 8.0
 * `tot-net-out`: Total network output bytes sent to this client. Added in Valkey 8.0

commands/client-no-touch.md

@@ -1,5 +1,5 @@
 The `CLIENT NO-TOUCH` command controls whether commands sent by the client will alter the LRU/LFU of the keys they access.
 
-When turned on, the current client will not change LFU/LRU stats, unless it sends the `TOUCH` command.
+When turned on, the current client will not change LFU/LRU stats, unless it sends the [`TOUCH`](touch.md) command.
 
 When turned off, the client touches LFU/LRU stats just as a normal client.

commands/client-pause.md

@@ -26,7 +26,7 @@ This command is useful as it makes able to switch clients from a Valkey instance
 * Reconfigure clients to connect with the new primary.
 
 The recommended mode for client pause is `WRITE`. This mode will stop all replication traffic, can be
-aborted with the `CLIENT UNPAUSE` command, and allows reconfiguring the old primary without risking accepting writes after the
+aborted with the [`CLIENT UNPAUSE`](client-unpause.md) command, and allows reconfiguring the old primary without risking accepting writes after the
 failover. This is also the mode used during cluster failover.
 
 This command also prevents keys to be evicted or expired during the time clients are paused.

commands/client-setinfo.md

@@ -1,4 +1,4 @@
-The `CLIENT SETINFO` command assigns various info attributes to the current connection which are displayed in the output of `CLIENT LIST` and `CLIENT INFO`.
+The `CLIENT SETINFO` command assigns various info attributes to the current connection which are displayed in the output of [`CLIENT LIST`](client-list.md) and [`CLIENT INFO`](client-info.md).
 
 Client libraries are expected to pipeline this command after authentication on all connections
 and ignore failures since they could be connected to an older version that doesn't support them.
@@ -9,4 +9,4 @@ Currently the supported attributes are:
 
 There is no limit to the length of these attributes. However it is not possible to use spaces, newlines, or other non-printable characters that would violate the format of the `CLIENT LIST` reply.
 
-Note that these attributes are **not** cleared by the RESET command.
+Note that these attributes are **not** cleared by the [`RESET`](reset.md) command.

commands/client-setname.md

@@ -1,14 +1,14 @@
 The `CLIENT SETNAME` command assigns a name to the current connection.
 
-The assigned name is displayed in the output of `CLIENT LIST` so that it is possible to identify the client that performed a given connection.
+The assigned name is displayed in the output of [`CLIENT LIST`](client-list.md) so that it is possible to identify the client that performed a given connection.
 
 For instance when Valkey is used in order to implement a queue, producers and consumers of messages may want to set the name of the connection according to their role.
 
 There is no limit to the length of the name that can be assigned if not the usual limits of the String type (512 MB). However it is not possible to use spaces in the connection name as this would violate the format of the `CLIENT LIST` reply.
 
 It is possible to entirely remove the connection name setting it to the empty string, that is not a valid connection name since it serves to this specific purpose.
 
-The connection name can be inspected using `CLIENT GETNAME`.
+The connection name can be inspected using [`CLIENT GETNAME`](client-getname.md).
 
 Every new connection starts without an assigned name.
 

commands/client-tracking.md

@@ -21,9 +21,9 @@ unless tracking is turned off with `CLIENT TRACKING off` at some point.
 The following are the list of options that modify the behavior of the
 command when enabling tracking:
 
-* `REDIRECT <id>`: send invalidation messages to the connection with the specified ID. The connection must exist. You can get the ID of a connection using `CLIENT ID`. If the connection we are redirecting to is terminated, when in RESP3 mode the connection with tracking enabled will receive `tracking-redir-broken` push messages in order to signal the condition.
+* `REDIRECT <id>`: send invalidation messages to the connection with the specified ID. The connection must exist. You can get the ID of a connection using [`CLIENT ID`](client-id.md). If the connection we are redirecting to is terminated, when in RESP3 mode the connection with tracking enabled will receive `tracking-redir-broken` push messages in order to signal the condition.
 * `BCAST`: enable tracking in broadcasting mode. In this mode invalidation messages are reported for all the prefixes specified, regardless of the keys requested by the connection. Instead when the broadcasting mode is not enabled, Valkey will track which keys are fetched using read-only commands, and will report invalidation messages only for such keys.
 * `PREFIX <prefix>`: for broadcasting, register a given key prefix, so that notifications will be provided only for keys starting with this string. This option can be given multiple times to register multiple prefixes. If broadcasting is enabled without this option, Valkey will send notifications for every key. You can't delete a single prefix, but you can delete all prefixes by disabling and re-enabling tracking. Using this option adds the additional time complexity of O(N^2), where N is the total number of prefixes tracked. 
-* `OPTIN`: when broadcasting is NOT active, normally don't track keys in read only commands, unless they are called immediately after a `CLIENT CACHING yes` command.
+* `OPTIN`: when broadcasting is NOT active, normally don't track keys in read only commands, unless they are called immediately after a [`CLIENT CACHING yes`](client-caching.md) command.
 * `OPTOUT`: when broadcasting is NOT active, normally track keys in read only commands, unless they are called immediately after a `CLIENT CACHING no` command.
 * `NOLOOP`: don't send notifications about keys modified by this connection itself.

commands/client-unblock.md

@@ -1,4 +1,4 @@
-This command can unblock, from a different connection, a client blocked in a blocking operation, such as for instance `BRPOP` or `XREAD` or `WAIT`.
+This command can unblock, from a different connection, a client blocked in a blocking operation, such as for instance [`BRPOP`](brpop.md) or [`XREAD`](xread.md) or [`WAIT`](wait.md).
 
 By default the client is unblocked as if the timeout of the command was
 reached, however if an additional (and optional) argument is passed, it is possible to specify the unblocking behavior, that can be **TIMEOUT** (the default) or **ERROR**. If **ERROR** is specified, the behavior is to unblock the client returning as error the fact that the client was force-unblocked. Specifically the client will receive the following error:
@@ -19,7 +19,7 @@ the new key, and issue the blocking command again.
 To obtain this behavior the following pattern is used. The process uses
 an additional *control connection* in order to send the `CLIENT UNBLOCK` command
 if needed. In the meantime, before running the blocking operation on the other
-connections, the process runs `CLIENT ID` in order to get the ID associated
+connections, the process runs [`CLIENT ID`](client-id.md) in order to get the ID associated
 with that connection. When a new key should be added, or when a key should
 no longer be monitored, the relevant connection blocking command is aborted
 by sending `CLIENT UNBLOCK` in the control connection. The blocking command

commands/client-unpause.md

@@ -1 +1 @@
-`CLIENT UNPAUSE` is used to resume command processing for all clients that were paused by `CLIENT PAUSE`.
+`CLIENT UNPAUSE` is used to resume command processing for all clients that were paused by [`CLIENT PAUSE`](client-pause.md).

commands/client.md

@@ -1,3 +1,3 @@
 This is a container command for client connection commands.
 
-To see the list of available commands you can call `CLIENT HELP`.
+To see the list of available commands you can call [`CLIENT HELP`](client-help.md).

commands/cluster-addslotsrange.md

@@ -1,4 +1,4 @@
-The `CLUSTER ADDSLOTSRANGE` is similar to the `CLUSTER ADDSLOTS` command in that they both assign hash slots to nodes.
+The `CLUSTER ADDSLOTSRANGE` is similar to the [`CLUSTER ADDSLOTS`](cluster-addslots.md) command in that they both assign hash slots to nodes.
 
 The difference between the two commands is that `CLUSTER ADDSLOTS` takes a list of slots to assign to the node, while `CLUSTER ADDSLOTSRANGE` takes a list of slot ranges (specified by start and end slots) to assign to the node.
 

commands/cluster-delslots.md

@@ -9,7 +9,7 @@ has consequently removed the associations for the passed hash slots,
 we say those hash slots are *unbound*. Note that the existence of
 unbound hash slots occurs naturally when a node has not been
 configured to handle them (something that can be done with the
-`CLUSTER ADDSLOTS` command) and if it has not received any information about
+[`CLUSTER ADDSLOTS`](cluster-addslots.md) command) and if it has not received any information about
 who owns those hash slots (something that it can learn from heartbeat
 or update messages).
 

commands/cluster-delslotsrange.md

@@ -1,4 +1,4 @@
-The `CLUSTER DELSLOTSRANGE` command is similar to the `CLUSTER DELSLOTS` command in that they both remove hash slots from the node.
+The `CLUSTER DELSLOTSRANGE` command is similar to the [`CLUSTER DELSLOTS`](cluster-deslots.md) command in that they both remove hash slots from the node.
 The difference is that `CLUSTER DELSLOTS` takes a list of hash slots to remove from the node, while `CLUSTER DELSLOTSRANGE` takes a list of slot ranges (specified by start and end slots) to remove from the node.
 
 ## Example

commands/cluster-failover.md

@@ -64,6 +64,6 @@ Because of this the **TAKEOVER** option should be used with care.
 * An `OK` reply is no guarantee that the failover will succeed.
 * A replica can only be promoted to a primary if it is known as a replica by a majority of the primaries in the cluster.
   If the replica is a new node that has just been added to the cluster (for example after upgrading it), it may not yet be known to all the primaries in the cluster.
-  To check that the primaries are aware of a new replica, you can send `CLUSTER NODES` or `CLUSTER REPLICAS` to each of the primary nodes and check that it appears as a replica, before sending `CLUSTER FAILOVER` to the replica.
-* To check that the failover has actually happened you can use `ROLE`, `INFO REPLICATION` (which indicates "role:master" after successful failover), or `CLUSTER NODES` to verify that the state of the cluster has changed sometime after the command was sent.
+  To check that the primaries are aware of a new replica, you can send [`CLUSTER NODES`](cluster-nodes.md) or [`CLUSTER REPLICAS`](cluster-replicas.md) to each of the primary nodes and check that it appears as a replica, before sending `CLUSTER FAILOVER` to the replica.
+* To check that the failover has actually happened you can use [`ROLE`](role.md), [`INFO REPLICATION`](info.md) (which indicates "role:master" after successful failover), or `CLUSTER NODES` to verify that the state of the cluster has changed sometime after the command was sent.
 * To check if the failover has failed, check the replica's log for "Manual failover timed out", which is logged if the replica has given up after a few seconds.

commands/cluster-getkeysinslot.md

@@ -6,9 +6,9 @@ Note that this works only when deleting keys, as the same `count` keys are
 returned on each call unless removed.
 
 The main usage of this command is during rehashing of cluster slots from one
-node to another. The way the rehashing is performed is exposed in the Valkey
-Cluster specification, or in a more simple to digest form, as an appendix
-of the `CLUSTER SETSLOT` command documentation.
+node to another. The way the rehashing is performed is exposed in the [Valkey
+Cluster specification](../topics/cluster-spec.md), or in a more simple to digest form, as an appendix
+of the [`CLUSTER SETSLOT`](cluster-setslot.md) command documentation.
 
 ```
 > CLUSTER GETKEYSINSLOT 7000 3