Pending entries

A pending entry is one a consumer group has delivered and nobody has finished. It is not lost and it is not a failure — it is work in flight — and this screen is where you find out whether it is still moving.

The streams to choose from come from the same list the Streams page shows, which names streams and nothing else, so anyone who may view the connection can open this screen — it is not a key listing. If that list cannot be read, the reason is shown where the entries would be, not an empty screen.

The picker is filled a page of the walk at a time, with Back and Next beside it, and the Pattern box narrows the walk to the stream names that match a glob — orders:* — as on the Streams page. The stream and group you choose are in the page's address, so a link opens on them, even a stream the walk has not reached yet, and a reload keeps them.

What the list tells you

For a chosen stream and group: how many entries are pending, the oldest and newest of them, and how many consumers are holding them, with a count beside each consumer.

Then the entries themselves — the entry id, which consumer owns it, how long it has been idle, and how many times it has been delivered.

At most 1,000 entries are listed, oldest first. When a group holds more, a warning under the table says how many of how many are shown and that these are the oldest; raise the minimum idle to narrow the list, or work through it in passes — acknowledging or claiming entries reveals the next ones.

The delivery count is the signal

An entry delivered once and still pending is normal work. An entry delivered five times and still pending is a message something keeps failing to process, and BROKA marks it: delivered N times and still not finished. Something keeps failing to process it — claiming it again is a retry, not a fix.

That last clause is the point. The instinct on finding a stuck entry is to claim it and let it be redelivered, and for a message that fails deterministically that produces a sixth failure. The signal is telling you to look at why, not to move it.

The list opens in the stream's own order, oldest entry id first, and a flagged entry is coloured where it sits rather than floated to the top, because its position among its neighbours is part of what you are reading. Every column sorts, so a click on Deliveries gathers the most-delivered entries when that is the question.

Claiming: the safety interlock

Claiming moves ownership of named entries to a consumer, so work abandoned by a process that died can be picked up by one that is alive.

The minimum idle time on that dialog is not a filter — it is an interlock, and BROKA fills it in, at 60 seconds, rather than leaving it out.

Redis will refuse to hand over any entry that has been touched more recently than the threshold. That is what stops two operators recovering the same backlog from taking each other's work mid-flight, and it is why the value cannot be zero by accident: zero disables the protection.

The result says what actually happened. If fewer entries came back than you named, the console tells you how many and why — the rest were touched more recently than the idle threshold — rather than reporting a partial success as success.

The list has its own minimum-idle box for narrowing what you are looking at. It is a different control from the interlock, and the hint under each says which is which.

Sweep to a consumer, in the page header, is the same act for the whole pending list rather than the rows you ticked: every entry idle longer than the threshold moves to the consumer you name, in one bounded pass, with the same interlock. The result says how many it claimed, whether more is left to sweep by running it again, and — on a server that reports it — how many pending entries Redis dropped because the stream data behind them was gone, so they could never be delivered.

Acknowledging does not delete

"Acknowledge" reads like "discard", so the console says what it actually does, twice — in the confirmation and in a standing note under the list.

Acknowledging removes an entry from this group's pending list and from nowhere else. The entry stays in the stream. Other groups still see it. A range read still returns it. What you have said is this group is finished with it, not this never happened.

When you mean both, Ack & delete, in the selection bar beside Acknowledge, acknowledges the selected entries and removes them from the stream in one step (Redis 8.2 and later). It carries the same Consumer groups choice as a stream trim, which says what the other groups keep: their pending references, nothing, or — with only what every group acknowledged — the entry itself, until every group has finished with it. On an older server the action is shown greyed out, with the reason.

Returning entries to the group

Return to group, in the selection bar beside Ack & delete, hands the selected entries back to their group without acknowledging them (Redis 8.8 and later). Nothing is acknowledged or deleted: the entries stay pending and in the stream, owned by no consumer, until a consumer of the group takes them. Until then their consumer and idle time read as a dash, and hovering it says the entry was returned to the group.

The dialog asks one thing, Delivery count, because returning an entry changes its delivery count — the count this screen reads as the poison signal, and the one a consumer's own retry limit reads:

Choice	What happens to each entry's delivery count
Failed here, may succeed elsewhere (FAIL)	It stays as it is.
Not the entry's fault (SILENT)	It goes back down by one, as if that delivery had not happened — the consumer stopped, or failed internally.
The entry is bad (FATAL)	It is set to its maximum, so a consumer that stops retrying after a number of deliveries will not take it again.

The result says how many entries were returned, and if some had stopped being pending in the meantime, that the rest were no longer pending. Nothing is lost, so it asks no reason. Like the other actions in the bar, it needs write permission on the connection. On an older server it is shown greyed out, with the reason.

Who may, and what asks why

The selection bar and Sweep to a consumer appear only where you may write to the connection; a read-only environment or a connection frozen with its own read-only switch refuses them. Ack & delete removes entries from the stream, so its confirmation asks for a reason in every environment. Claiming, sweeping, acknowledging and returning to the group ask for one only in a guarded environment, where every write does.

Claim and Sweep to a consumer also take Read message contents (messages.read), because the server answers with the entries they moved; without it they are shown disabled, with the reason. Where a data masking rule covers the stream, those entries are returned as they are only to someone who also holds Read masked contents unmasked (messages.read.unmasked) for it — on its environment or connection, or by a key grant whose pattern matches the stream's name.

Masked fields

The pending list holds ids, owners, idle times and delivery counts — no contents — so a data masking rule changes nothing on it. Claim and Sweep to a consumer answer with the entries they moved, and where a rule covers the stream, those entries come back masked, field by field, as they read on the Streams page. The console shows only how many were claimed. Claiming an entry with masked fields is not refused: its ownership moves within the group, and nothing is copied anywhere.

Pending is not lost

The note under the list exists because the word invites the wrong conclusion. An entry sitting in a pending list is delivered-and-unfinished, and the ways out of that state are finishing it — acknowledging, or acknowledging and deleting — handing it to a consumer that can, or returning it to the group for whichever consumer takes it next.