Redis 6.2 RC2 combines pending-message discovery and claiming
XAUTOCLAIM adds cursor-based recovery of stale stream deliveries. Redis 6.2 RC2 also expands ZRANGE, while documenting platform and compatibility changes that affect candidate evaluation.
Recovering messages from an inactive stream consumer requires finding eligible pending entries and transferring their ownership. Redis 6.2 RC2 adds a command that combines those tasks. XAUTOCLAIM reduces the client-side exchange needed for that recovery while exposing a cursor so the work can proceed incrementally. Its design also shows a deliberate choice about the memory cost of maintaining another index.
The 6.2 release notes date the second release candidate to January 12. The RC2-tagged notes preserve the changes available at this point. They identify XAUTOCLAIM and expanded sorted-set range operations as additions since RC1. This is a candidate for testing, rather than a stable release announcement.
I have used Redis since its early releases, and its command model remains appealing to me. A focused server operation can remove application coordination when it captures the intended behavior precisely. XAUTOCLAIM is useful in that sense because the change concerns a recognizable recovery operation, with explicit eligibility and continuation arguments.
Claiming uses a scan-like cursor
The XAUTOCLAIM proposal, merged on January 6, explains the previous exchange as a combination of XPENDING and XCLAIM. One command discovers pending entries, and another claims them. The new command combines the work so that the client does not need those two round trips for the same recovery step.
Its arguments identify the stream, consumer group and receiving consumer. A minimum idle time restricts which pending entries are eligible. A starting stream ID controls where scanning begins. The optional COUNT and JUSTID arguments modify the request further. That explicit minimum-idle argument matters because a pending delivery is not automatically evidence that its consumer has failed.
An example command using the proposal's syntax is:
XAUTOCLAIM jobs workers recovery-worker 60000 0-0 COUNT 100
Here jobs, workers and recovery-worker are illustrative names for an existing stream, group and receiving consumer. The command starts at 0-0 and supplies a minimum idle-time argument of 60000. It is a recovery command for that existing group, not a command that creates all the named resources.
The reply supplies a stream-ID cursor for the next call. The proposal says that a returned 0-0 means the scan is complete. A caller should therefore preserve the returned cursor instead of repeatedly substituting the original starting point. The continuation mechanism is part of the operation's contract, rather than an incidental field in the response.
This design separates eligible work from the position of the scan. The idle-time threshold expresses the recovery policy, while the cursor expresses progress through the pending entries. Combining discovery and claiming does not remove either concern. It makes them available through one command invocation.
Another index would change the memory tradeoff
The proposal considers an alternative design based on an idle-time index. Such an index could avoid scan-like continuation for this purpose. The author estimates that an additional radix tree would add roughly fifty percent memory overhead for streams with consumer groups. That is a design estimate in the proposal, not a measured increase claimed for XAUTOCLAIM itself.
The chosen cursor approach retains a client loop in exchange for avoiding that proposed indexing cost. This gives the new command a more specific rationale than simply expanding the command list. It reduces the discovery-and-claim exchange while accepting incremental scanning as part of recovery.
I prefer that explicit tradeoff to an API description that hides all remaining work behind the word automatic. A client still needs to choose an idle threshold and continue scanning. The server now supplies the combined operation, and the proposal explains why the implementation does not maintain an additional ordering solely for this recovery path.
Sorted-set range selection gains common syntax
RC2 also incorporates the ZRANGE and ZRANGESTORE change, merged on January 7. ZRANGE gains BYSCORE, BYLEX and REV, with LIMIT available in the extended syntax. The proposal retains the older rank-based ZRANGE form while bringing other selection modes into the same command.
ZRANGESTORE uses related selection arguments but writes the selected range to a destination sorted set. The implementation shares selection code through a consumer interface. One consumer produces a client reply, while the other stores a sorted-set key. This is a concrete reason the selection semantics can remain aligned between returning a range and storing it.
The proposal says the other range commands remain unchanged. That qualification prevents interpreting the new syntax as immediate removal of established commands. Existing callers can continue using their current forms while new callers can express direction and selection mode through the expanded ZRANGE arguments.
Candidate compatibility includes platform behavior
The RC2 notes also identify changes whose relevance depends on the deployment. A corrected RDB CRC64 checksum on big-endian systems has compatibility implications for persistence, replication and RESTORE. A new check detects an ARM64 Linux kernel bug and refuses to run on affected platforms by default because of its potential severity.
Lua response behavior receives another explicit warning. The candidate fixes key/value ordering in Lua map responses, and asks users of redis.setresp() or map returns to consider the implications. These are existing behaviors corrected alongside the command additions. A command-focused evaluation of RC2 would omit them.
Inspection also becomes more specific. RC2 adds an errorstats section to INFO, and adds failed_calls and rejected_calls fields to its command statistics. Those counters distinguish reported command outcomes more clearly than a count of invocations alone. The same notes describe continuous reporting of child copy-on-write metrics. These additions provide observations about execution and resource behavior alongside the new command arguments. They do not supply a benchmark for the candidate, but they identify information available to users investigating its behavior under their own workloads.
For stream users, the immediate API change is a combined recovery operation with cursor continuation. For sorted-set users, the candidate supplies common range syntax and a storage counterpart. The tagged notes retain the platform qualifications needed to interpret whether the same candidate changes persistence compatibility or startup behavior in a particular deployment.