Describe the bug
In our implementation, after reading messages from stream (with XREADGROUP), we delete it from the stream(with XDEL). In this case, messages stay in Pending Entities List, which leads to OOM at some point.
To reproduce
We use XADD to add messages, XREAD GROUP to read them, XDEL to delete, and XINFO STREAM FULL to check PEL-count.
Expected behavior
Messages, deleted from the stream with XDEL, should probably be deleted from the PEL too, without explicit XACK. Or, if there is a reason for current behavior to be expected, it should be documented to be clear.
Comment From: sundb
did you forget to XACK
?
Comment From: trilga
We assumed that there is no need to XACK if we do XDEL. I'll update description to make it clearer
Comment From: sundb
@trilga XDEL
is not responsible for removing entry from PEL.
Comment From: trilga
So, the question is why? Intuitively one would expect that you don't need to acknowledge receiving the message if you delete it. Could you please elaborate more on this?
Comment From: sundb
it has to do with their duties.
XACK
is for PEL, XDEL
is for stream.
if one mesage is deleted by XDEL
, we still need to know the message hasn't been processed.
Comment From: trilga
@sundb, thank you, I think I understood the behavior! Do you think it is possible to add this information to the documentation? The first impression is that XDEL would delete the message from all of the storages. So it might be helpful to point out that the deleted message stays in PEL waiting for acknowledgment. BTW, I found out that the XCLAIM attempt on such a message also removes it from PEL
Comment From: sundb
@trilga in fact, the document is clear, and the document for XDEL
doesn't say that it will clean PEL.
https://redis.io/docs/latest/commands/xack/
https://redis.io/docs/latest/commands/xdel/
The XACK command removes one or multiple messages from the Pending Entries List (PEL) of a stream consumer 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](https://redis.io/docs/latest/commands/xreadgroup/), or when a consumer took ownership of a message calling [XCLAIM](https://redis.io/docs/latest/commands/xclaim/).
Comment From: sundb
@trilga We have added a new XDELEX command in https://github.com/redis/redis/pull/14130 to support the simultaneous deletion of PEL when deleting elements.