XPENDING key group [start end count] [consumer]

Time complexity: O(N) with N being the number of elements returned, so asking for a small fixed number of entries per call is O(1). When the command returns just the summary it runs in O(1) time assuming the list of consumers is small, otherwise there is additional O(N) time needed to iterate every consumer.

Fetching data from a stream via a consumer group, and not acknowledging such data, has the effect of creating pending entries. This is well explained in the command, and even better in our introduction to Redis Streams. The command will immediately remove the pending entry from the Pending Entry List (PEL) since once a message is successfully processed, there is no longer need for the consumer group to track it and to remember the current owner of the message.

The XPENDING command is the interface to inspect the list of pending messages, and is as thus a very important command in order to observe and understand what is happening with a streams consumer groups: what clients are active, what messages are pending to be consumed, or to see if there are idle messages. Moreover this command, together with is used in order to implement recovering of consumers that are failing for a long time, and as a result certain messages are not processed: a different consumer can claim the message and continue. This is better explained in the streams intro and in the command page, and is not covered here.

We expect the pending entries list for the consumer group to have a message right now: consumer named consumer-123 fetched the message without acknowledging its processing. The simple XPENDING form will give us this information:

In this form, the command outputs the total number of pending messages for this consumer group, which is one, followed by the smallest and greatest ID among the pending messages, and then list every consumer in the consumer group with at least one pending message, and the number of pending messages it has.

This is a good overview, but sometimes we are interested in the details. In order to see all the pending messages with more associated information we need to also pass a range of IDs, in a similar way we do it with , and a non optional count argument, to limit the number of messages returned per call:

• The ID of the message.
• The number of milliseconds that elapsed since the last time this message was delivered to this consumer.

Finally it is possible to pass an additional argument to the command, in order to see the messages having a specific owner:

But in the above case the output would be the same, since we have pending messages only for a single consumer. However what is important to keep in mind is that this operation, filtering by a specific consumer, is not inefficient even when there are many pending messages from many consumers: we have a pending entries list data structure both globally, and for every consumer, so we can very efficiently show just messages pending for a single consumer.

*Return value

Array reply, specifically: