[5.0.3] [Stream] message stays in PEL after deleting

[bagbag]

I'm not sure wether this behavior is wanted or not, but I did not expected that a message is returned with xpending after deleting it. I did not found any statement about the desired behavior in the documentation.

Reproduction

127.0.0.1:6379> xgroup CREATE stream group $ MKSTREAM
OK
127.0.0.1:6379> xadd stream * foo bar
"1545511203225-0"
127.0.0.1:6379> xreadgroup GROUP group consumer STREAMS stream >
1) 1) "stream"
   2) 1) 1) "1545511203225-0"
         2) 1) "foo"
            2) "bar"
127.0.0.1:6379> xdel stream 1545511203225-0
(integer) 1
127.0.0.1:6379> xpending stream group - + 10
1) 1) "1545511203225-0"
   2) "consumer"
   3) (integer) 46208
   4) (integer) 1
127.0.0.1:6379> xrange stream - +
(empty list or set)

Off Topic (question)

My goal is to create a queue. When I've get long pending entries (for whatever reason), I obviously want consumers to retry it. But I dont want to manually select the new consumer, but rather something like "give it the next free consumer (using XREADGROUP)". Thats why I just delete the entries and add them again with an transaction to let redis take care of consumer selection. Something like an "automated" XCLAIM on XREADGROUP for that consumer would be nice to be able to use the delivery counter and keep the same ID (but probably doesn't fit well into the API design, at least I didn't come up with something nice). With my method I have to alter the entry (with an in-data delivery counter) and must accept a new ID.

Am I missing something or is that the only way of achieving that?

[soloestoy]

It seems by designed, the pending entry list just contains entries have not received ACK, PEL doesn't care about the entry is existed or not, but I'm not sure, ping @antirez here. BTW XTRIM could lead to the issue too.

[soloestoy]

Related to #5754, it's by designed.