Repository navigation
Streams: a history read of a pending entry that was trimmed drops it on replicas and after AOF replay (as in Redis) #737
Description
Found while testing #736 (per-consumer PEL index). Redis 8.10.2 behaves the same way, so this is parity, but master and replica end up with different pending lists.
Repro (primary + replica, or primary with AOF):
- A consumer has an entry pending, then the entry is trimmed from the stream (
XTRIM/MAXLEN) while it stays in the group's PEL. - The consumer reads its history (
XREADGROUP GROUP g c STREAMS s 0). On the primary this bumps the pending entry's delivery count and keeps it pending. - That read is replicated as
XCLAIM s g c 0 <id> ... FORCE JUSTID .... On the replica (and on AOF replay) the XCLAIM of an ID that no longer exists in the stream removes it from the PEL.
Result: the primary still has the entry pending; the replica and a restarted primary do not. XPENDING differs between them.
Verified against Redis 8.10.2 primary/replica: both replicas lose the entry. Options:
- keep parity (document it as a known Redis behaviour), or
- replicate the history-read side effect in a form that keeps a trimmed pending entry (e.g. don't propagate the claim for entries no longer in the stream, since only the delivery count/time changes), and check the AOF replays to the same state.
Low priority; affects only pending entries whose stream entry was trimmed or deleted.
Activity