Skip to content

Fix XREADGROUP CLAIM to return delivery metadata as integers#14524

Merged
sundb merged 8 commits intoredis:unstablefrom
sggeorgiev:fix_claim_fileds_type
Nov 11, 2025
Merged

Fix XREADGROUP CLAIM to return delivery metadata as integers#14524
sundb merged 8 commits intoredis:unstablefrom
sggeorgiev:fix_claim_fileds_type

Conversation

@sggeorgiev
Copy link
Collaborator

Problem

The XREADGROUP command with CLAIM parameter incorrectly returns delivery metadata (idle time and delivery count) as strings instead of integers, contradicting the Redis specification.

Solution

Updated the XREADGROUP CLAIM implementation to return delivery metadata fields as integers, aligning with the documented specification and maintaining consistency with Redis response conventions.

@sundb
Copy link
Collaborator

sundb commented Nov 10, 2025

is it needed to be changed?

                                        {
                                            "description": "Milliseconds elapsed since last delivery",
                                            "type": "string"
                                        },
                                        {
                                            "description": "Delivery count (0 for new messages, 1+ for claimed messages)",
                                            "type": "string"
                                        }

https://github.com/sundb/redis/actions/runs/19230866050
let's see if schema CI can detect it.

@sundb
Copy link
Collaborator

sundb commented Nov 10, 2025

@sundb
Copy link
Collaborator

sundb commented Nov 11, 2025

Skip this test when force_resp3 is true?

diff --git a/tests/unit/type/stream-cgroups.tcl b/tests/unit/type/stream-cgroups.tcl
index d9a77ac20..132b69299 100644
--- a/tests/unit/type/stream-cgroups.tcl
+++ b/tests/unit/type/stream-cgroups.tcl
@@ -1879,10 +1879,8 @@ start_server {
     }
     
     start_server {} {
+        if {!$::force_resp3} {
         test "XREADGROUP CLAIM field types are correct" {
-            # This test checks raw RESP2 protocol format
-            r hello 2
-            
             r DEL mystream
             r XADD mystream 1-0 f v1
             r XGROUP CREATE mystream group1 0
@@ -1923,13 +1921,11 @@ start_server {
             set idle_time_type [r read]
             assert_match {:*} $idle_time_type "Expected idle time to be integer type (:), got: $idle_time_type"
         }
+        }
 
         # Restore connection state
         r readraw 0
         r deferred 0
-        if {$::force_resp3} {
-            r hello 3
-        }
 
         test "XREADGROUP CLAIM returns unacknowledged messages" {
             r DEL mystream

@sundb
Copy link
Collaborator

sundb commented Nov 11, 2025

@sundb sundb added this to Redis 8.6 Nov 11, 2025
@sundb sundb removed this from Redis 8.6 Nov 11, 2025
@sundb sundb added this to Redis 8.4 Nov 11, 2025
@sundb sundb merged commit 90ba7ba into redis:unstable Nov 11, 2025
23 checks passed
@github-project-automation github-project-automation bot moved this from Todo to Done in Redis 8.4 Nov 11, 2025
@sundb sundb mentioned this pull request Nov 18, 2025
sundb added a commit that referenced this pull request Nov 18, 2025
This is the General Availability release of Redis 8.4 in Redis Open
Source.

### Major changes compared to 8.2

- `DIGEST`, `DELEX`; `SET` extensions - atomic compare-and-set and
compare-and-delete for string keys
- `MSETEX` - atomically set multiple string keys and update their
expiration
- `XREADGROUP` - new `CLAIM` option for reading both idle pending and
incoming stream entries
- `CLUSTER MIGRATION` - atomic slot migration
- `CLUSTER SLOT-STATS` - per-slot usage metrics: key count, CPU time,
and network I/O
- Redis query engine: `FT.HYBRID` - hybrid search and fused scoring
- Redis query engine: I/O threading with performance boost for search
and query commands (FT.*)
- I/O threading: substantial throughput increase (e.g. >30% for caching
use cases (10% `SET`, 90% `GET`), 4 cores)
- JSON: substantial memory reduction for homogenous arrays (up to 91%)

### Binary distributions

- Alpine and Debian Docker images - https://hub.docker.com/_/redis
- Install using snap - see https://github.com/redis/redis-snap
- Install using brew - see https://github.com/redis/homebrew-redis
- Install using RPM - see https://github.com/redis/redis-rpm
- Install using Debian APT - see https://github.com/redis/redis-debian


### Operating systems we test Redis 8.4 on

- Ubuntu 22.04 (Jammy Jellyfish), 24.04 (Noble Numbat)
- Rocky Linux 8.10, 9.5
- AlmaLinux 8.10, 9.5
- Debian 12 (Bookworm), Debian 13 (Trixie)
- macOS 13 (Ventura), 14 (Sonoma), 15 (Sequoia)

### Bug fixes (compared to 8.4-RC1)

- #14524 `XREADGROUP CLAIM` returns strings instead of integers
- #14529 Add variable key-spec flags to SET IF* and DELEX
- #P928 Potential memory leak (MOD-11484)
- #T1801, #T1805 macOS build failures (MOD-12293)
- #J1438 `JSON.NUMINCRBY` - wrong result on integer array with
non-integer increment (MOD-12282)
- #J1437 Thread safety issue related to ASM and shared strings
(MOD-12013)


### Performance and resource utilization improvements (compared to
8.4-RC1)

- #14480, #14516 Optimize `XREADGROUP`

### known bugs and limitations

- When executing `FT.SEARCH`, `FT.AGGREGATE`, `FT.CURSOR`, `FT.HYBRID`,
`TS.MGET`, `TS.MRANGE`, `TS.MREVRANGE` and `TS.QUERYINDEX` while an
atomic slot migration process is in progress, the results may be partial
or contain duplicates
- `FT.PROFILE`, `FT.EXPLAIN` and `FT.EXPLACINCLI` doesn’t contain the
`FT.HYBRID` option
- Metrics from `FT.HYBRID` command aren’t displayed on `FT.INFO` and
`INFO`
- Option `EXPLAINSCORE`, `SHARD_K_RATIO`, `YIELD_DISTANCE_AS` and
`WITHCURSOR` with `FT.HYBRID` are not available
- Post-filtering (after `COMBINE` step) using FILTER is not available
- Currently the default response format considers only `key_id` and
`score`, this may change for delivering entire document content
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants