Docs Originality Update - Batch #9

docs/command-reference/stream/xack.md

@@ -1,5 +1,5 @@
 ---
-description:  Learn how to use Redis XACK to acknowledge the processing of a message from a stream by a consumer.
+description: Learn how to use Redis XACK to acknowledge the processing of a message from a stream by a consumer.
 ---
 
 import PageTitle from '@site/src/components/PageTitle';
@@ -8,26 +8,87 @@ import PageTitle from '@site/src/components/PageTitle';
 
 <PageTitle title="Redis XACK Command (Documentation) | Dragonfly" />
 
-## Syntax
+## Introduction
+
+In Dragonfly, as well as in Redis and Valkey, the `XACK` command is used to acknowledge one or more messages in a stream that have been successfully processed.
+This is particularly useful in stream processing systems where consumers must signal that a message has been handled, helping to manage message delivery and retention more efficiently within a consumer group.
 
-    XACK key group id [id ... ]
+## Syntax
 
-**Time complexity:** O(1) for each message ID processed.
+```shell
+XACK key group id [id ...]
+```
 
-**ACL categories:** @write, @stream, @fast
+## Parameter Explanations
 
-**XACK** command acknowledges one or more messages by removing the messages from the pending entries list (PEL) of the specified consumer stream group. A message is pending, and as such stored inside the PEL, when it was delivered to some consumer, normally as a side effect of calling XREADGROUP, or when a consumer took ownership of a message calling XCLAIM. The pending message was delivered to some consumer but the server is yet not sure it was processed at least once. So new calls to XREADGROUP to grab the messages history for a consumer (for instance using an ID of 0), will return such message. Similarly the pending message will be listed by the XPENDING command, that inspects the PEL. Once a consumer successfully processes a message, it should call **XACK** so that such message does not get processed again, and as a side effect, the PEL entry about this message is also purged, releasing memory from the Dragonfly server.
+- `key`: The name of the stream.
+- `group`: The name of the consumer group.
+- `id`: The ID of the message to acknowledge. Multiple IDs can be specified.
 
+## Return Values
 
-## Return
+The command returns an integer indicating the number of messages that were successfully acknowledged.
 
-[Integer reply](https://redis.io/docs/reference/protocol-spec/#integers), specifically:
+## Code Examples
 
-The command returns the number of messages successfully acknowledged. Certain message IDs may no longer be part of the PEL (for example because they have already been acknowledged), and XACK will not count them as successfully acknowledged.
+### Basic Acknowledgement Example
 
-## Examples
+Acknowledge a single message that has been processed:
 
 ```shell
-dragonfly> XACK mystream mygroup 1526569495631-0
+dragonfly$> XADD mystream * name Alice age 30
+"1609097574170-0"
+dragonfly$> XGROUP CREATE mystream mygroup $ MKSTREAM
+OK
+dragonfly$> XREADGROUP GROUP mygroup Alice COUNT 1 STREAMS mystream >
+1) 1) "mystream"
+   2) 1) 1) "1609097574170-0"
+         2) 1) "name"
+            2) "Alice"
+            3) "age"
+            4) "30"
+dragonfly$> XACK mystream mygroup 1609097574170-0
 (integer) 1
 ```
+
+### Acknowledging Multiple Messages
+
+Acknowledge multiple messages after processing:
+
+```shell
+dragonfly$> XADD mystream * name Bob age 25
+"1609097574171-0"
+dragonfly$> XADD mystream * name Charlie age 40
+"1609097574172-0"
+dragonfly$> XACK mystream mygroup 1609097574171-0 1609097574172-0
+(integer) 2
+```
+
+### Handling Non-existent IDs
+
+Acknowledge attempt on a non-existent message ID:
+
+```shell
+dragonfly$> XACK mystream mygroup 1609097574173-0
+(integer) 0  # No acknowledgment since the ID does not exist.
+```
+
+## Best Practices
+
+- Use `XACK` to signal message processing completion to avoid reprocessing.
+- Implement proper error handling to manage message IDs that may no longer exist or are not yet acknowledged.
+
+## Common Mistakes
+
+- Not creating a consumer group before attempting to acknowledge messages; `XACK` requires a valid consumer group.
+- Attempting to acknowledge messages using IDs that were never read by the group.
+
+## FAQs
+
+### What happens if the message ID is not found?
+
+If the message ID does not exist in the pending entries list of the consumer group, `XACK` returns `0`.
+
+### Can `XACK` be used for automatic acknowledgement?
+
+No, `XACK` requires explicit calls to acknowledge messages after successful processing by consumers.

docs/command-reference/stream/xinfo-groups.md

@@ -1,5 +1,5 @@
 ---
-description:  Learn how to use Redis XINFO GROUPS to get information about consumer groups of a stream.
+description: Learn how to use Redis XINFO GROUPS to get information about consumer groups of a stream.
 ---
 
 import PageTitle from '@site/src/components/PageTitle';
@@ -8,47 +8,90 @@ import PageTitle from '@site/src/components/PageTitle';
 
 <PageTitle title="Redis XINFO GROUPS Command (Documentation) | Dragonfly" />
 
+## Introduction
+
+In Dragonfly, as well as in Redis and Valkey, the `XINFO GROUPS` command provides information about consumer groups associated with a specific stream.
+This command is essential for monitoring and managing stream processing tasks, providing insights into consumer group configurations and activity.
+
 ## Syntax
 
-	XINFO GROUPS key
+```shell
+XINFO GROUPS key
+```
 
-**ACL categories:** @read, @stream, @slow
+## Parameter Explanations
 
-**XINFO GROUPS** command returns details of every consumer group
-that belong to the specified stream **<key\>**.
+- `key`: The key of the stream for which consumer groups information is requested.
 
-The command returns the following details for each group:
+## Return Values
 
- * **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 to the
- group's consumers.
+The command returns a list of dictionaries, each dictionary representing a consumer group and its details.
+The details include fields such as `name`, `consumers`, `pending`, `last-delivered-id`, etc.
 
-## Return
+## Code Examples
 
-[Array reply](https://redis.io/docs/reference/protocol-spec/#arrays):
-a list of consumer groups.
+### Basic Example
 
-## Example
+Get information about consumer groups for a stream:
 
 ```shell
-dragonfly> XINFO GROUPS mystream
+dragonfly$> XGROUP CREATE mystream mygroup $
+OK
+dragonfly$> XINFO GROUPS mystream
 1) 1) "name"
    2) "mygroup"
    3) "consumers"
-   4) (integer) 2
+   4) (integer) 0
+   5) "pending"
+   6) (integer) 0
+   7) "last-delivered-id"
+   8) "0-0"
+```
+
+### Monitor Multiple Consumer Groups
+
+Creating and monitoring multiple consumer groups:
+
+```shell
+dragonfly$> XGROUP CREATE mystream group1 $
+OK
+dragonfly$> XGROUP CREATE mystream group2 $
+OK
+dragonfly$> XINFO GROUPS mystream
+1) 1) "name"
+   2) "group1"
+   3) "consumers"
+   4) (integer) 0
    5) "pending"
-   6) (integer) 10
+   6) (integer) 0
    7) "last-delivered-id"
-   8) "1623910467320-1"
+   8) "0-0"
 2) 1) "name"
-   2) "another-group"
+   2) "group2"
    3) "consumers"
-   4) (integer) 1
+   4) (integer) 0
    5) "pending"
-   6) (integer) 1
+   6) (integer) 0
    7) "last-delivered-id"
-   8) "1623910847311-1"
+   8) "0-0"
 ```
+
+## Best Practices
+
+- Regularly use `XINFO GROUPS` to check on the health and status of consumer groups in your stream processing architecture.
+- Ensure consumer groups are correctly created with unique and descriptive names to avoid confusion and manage them effectively.
+
+## Common Mistakes
+
+- Omitting the `key` parameter, which is necessary to identify the stream for which group information is needed.
+- Assuming that `XINFO GROUPS` modifies consumer groups; it only retrieves information.
+
+## FAQs
+
+### What happens if the stream key does not exist?
+
+If the stream key does not exist, `XINFO GROUPS` returns an empty list as there are no consumer groups associated with a nonexistent stream.
+
+### Can `XINFO GROUPS` be used on keys that are not streams?
+
+No, `XINFO GROUPS` is specific to streams, and attempting to use it on a non-stream key will result in an error.