Describe the bug

The XGROUP CREATE command's ENTRIESREAD parameter has two issues: 1) It allows setting entries_read values higher than the stream's entries_added, resulting in impossible negative lag values, and 2) The documentation incorrectly describes the parameter as accepting a stream ID for automatic calculation, when it actually accepts a direct numeric value with no calculation performed.

From Redis docs:

To enable consumer group lag tracking, specify the optional entries_read named argument with an arbitrary ID. An arbitrary ID is any ID that isn't the ID of the stream's first entry, last entry, or zero ("0-0") ID. Use it to find out how many entries are between the arbitrary ID (excluding it) and the stream's last entry. Set the entries_read the stream's entries_added subtracted by the number of entries.

To reproduce

127.0.0.1:6379> XADD mystream * field1 value1
"1754398908470-0"
127.0.0.1:6379> XGROUP CREATE mystream mygroup $ ENTRIESREAD 100
OK
127.0.0.1:6379> XINFO GROUPS mystream
1)  1) "name"
    2) "mygroup"
    3) "consumers"
    4) (integer) 0
    5) "pending"
    6) (integer) 0
    7) "last-delivered-id"
    8) "1754398908470-0"
    9) "entries-read"
   2) (integer) 100
   3) "lag"
   4) (integer) -99

Expected behavior

7) "lag"
8) (integer) 0  # or -1, or error during creation

The lag does not recover from this state, as far as I can see.

Additional information

This also affects XGROUP SETID command which accepts the same ENTRIESREAD parameter.

I'm curious whether this was the expected behavior and whether you expect valid values from the user, or should such requests be rejected or report invalid lag?

Comment From: giuseppe-coco

Hello, in my opnion a check over entries_read would be good. This would prevent incorrect lag. I opened a PR that simply checks if entries_read is greater than s->entries_added, i.e. the total number of elements in the stream. If so, we reply with an error.