The problem/use-case that the feature addresses
It appears that, by design, the below scenario is totally possible and leads to unclaimable "ghost" PEL entries.
# oO0OoO0OoO0Oo Immabe a ghost PEL entry oO0OoO0OoO0Oo
127.0.0.1:6379> XGROUP CREATE s g $ mkstream
OK
127.0.0.1:6379> XADD s * a b
"1636048926161-0"
127.0.0.1:6379> XREADGROUP GROUP g c STREAMS s >
1) 1) "s"
2) 1) 1) "1636048926161-0"
2) 1) "a"
2) "b"
127.0.0.1:6379> XPENDING s g
1) (integer) 1
2) "1636048926161-0"
3) "1636048926161-0"
4) 1) 1) "c"
2) "1"
127.0.0.1:6379> XGROUP DELCONSUMER s g c
(integer) 1
127.0.0.1:6379> XPENDING s g
1) (integer) 0
2) (nil)
3) (nil)
4) (nil)
127.0.0.1:6379> XINFO CONSUMERS s g
(empty array)
Description of the feature
Alternative 1: break compatibility and refuse to delete the consumer if it has pending messages unless a special modifier - e.g. FORCE - is provided.
Alternative 2: extend the syntax with a new modifier, e.g. NOPENDING, so once given the command will error if the PEL's length neq 0.
Alternatives you've considered
Currently, the docs (blame me) make excuses for this behavior and shift all the responsibility to the user:
Note, however, that any pending messages that the consumer had will become unclaimable after it was deleted. It is strongly recommended, therefore, that any pending messages are claimed or acknowledged prior to deleting the consumer from the group.
A client could (possibly, I didn't test) use a WATCH/MULTI/EXEC for this, or a Lua script.... but it shouldn't be that hard to ensure consistency.
Comment From: guybe7
I don't think there's an issue here... 1. it makes sense that if one explicitly deletes a consumer it implicitly says that one doesn't care about its PEL entries 2. it's well documented
Comment From: oranagra
@itamarhaber @guybe7 shall we close this or promote it in next version?
Comment From: itamarhaber
I think we can close this for now.