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.