diff --git a/commands/slowlog-get.md b/commands/slowlog-get.md index a99910ad87..3773cfbcd3 100644 --- a/commands/slowlog-get.md +++ b/commands/slowlog-get.md @@ -21,6 +21,6 @@ The entry's unique ID can be used in order to avoid processing slow log entries The ID is never reset in the course of the Redis server execution, only a server restart will reset it. -@reply +@return @array-reply: a list of slow log entries. diff --git a/commands/slowlog-len.md b/commands/slowlog-len.md index 6f0d97758a..6cc062f2a1 100644 --- a/commands/slowlog-len.md +++ b/commands/slowlog-len.md @@ -5,7 +5,7 @@ The maximum number of entries in the slow log is governed by the `slowlog-max-le Once the slog log reaches its maximal size, the oldest entry is removed whenever a new entry is created. The slow log can be cleared with the `SLOWLOG RESET` command. -@reply +@return @integer-reply diff --git a/commands/slowlog-reset.md b/commands/slowlog-reset.md index b522c26a5c..2b6d436aaf 100644 --- a/commands/slowlog-reset.md +++ b/commands/slowlog-reset.md @@ -2,6 +2,6 @@ This command resets the slow log, clearing all entries in it. Once deleted the information is lost forever. -@reply +@return @simple-string-reply: `OK` diff --git a/commands/xinfo-consumers.md b/commands/xinfo-consumers.md index 965292e131..d4bb878b8e 100644 --- a/commands/xinfo-consumers.md +++ b/commands/xinfo-consumers.md @@ -7,7 +7,7 @@ The following information is provided for each consumer in the group: * **idle**: the number of milliseconds that have passed since the consumer's last attempted interaction (Examples: `XREADGROUP`, `XCLAIM`, `XAUTOCLAIM`) * **inactive**: the number of milliseconds that have passed since the consumer's last successful interaction (Examples: `XREADGROUP` that actually read some entries into the PEL, `XCLAIM`/`XAUTOCLAIM` that actually claimed some entries) -@reply +@return @array-reply: a list of consumers. diff --git a/commands/xinfo-groups.md b/commands/xinfo-groups.md index 03eafecfa2..08af1c9ae1 100644 --- a/commands/xinfo-groups.md +++ b/commands/xinfo-groups.md @@ -1,12 +1,12 @@ -This command returns the list of all consumers groups of the stream stored at ``. +This command returns the list of all consumer groups of the stream stored at ``. By default, only the following information is provided for each of the groups: * **name**: the consumer group's name * **consumers**: the number of consumers in the group * **pending**: the length of the group's pending entries list (PEL), which are messages that were delivered but are yet to be acknowledged -* **last-delivered-id**: the ID of the last entry delivered the group's consumers -* **entries-read**: the logical "read counter" of the last entry delivered to group's consumers +* **last-delivered-id**: the ID of the last entry delivered to the group's consumers +* **entries-read**: the logical "read counter" of the last entry delivered to the group's consumers * **lag**: the number of entries in the stream that are still waiting to be delivered to the group's consumers, or a NULL when that number can't be determined. ### Consumer group lag @@ -22,7 +22,7 @@ The lag is the difference between these two. The stream's counter (the `entries_added` field of the `XINFO STREAM` command) is incremented by one with every `XADD` and counts all of the entries added to the stream during its lifetime. -The consumer group's counter, `entries_read`, is the logical counter of entries that the group had read. +The consumer group's counter, `entries_read`, is the logical counter of entries the group had read. It is important to note that this counter is only a heuristic rather than an accurate counter, and therefore the use of the term "logical". The counter attempts to reflect the number of entries that the group **should have read** to get to its current `last-delivered-id`. The `entries_read` counter is accurate only in a perfect world, where a consumer group starts at the stream's first entry and processes all of its entries (i.e., no entries deleted before processing). @@ -39,7 +39,7 @@ However, the lag is only temporarily unavailable. It is restored automatically during regular operation as consumers keep processing messages. Once the consumer group delivers the last message in the stream to its members, it will be set with the correct logical read counter, and tracking its lag can be resumed. -@reply +@return @array-reply: a list of consumer groups.