summaryrefslogtreecommitdiff
path: root/src/commands
diff options
context:
space:
mode:
authorguybe7 <guy.benoish@redislabs.com>2022-02-08 09:20:09 +0100
committerGitHub <noreply@github.com>2022-02-08 10:20:09 +0200
commit3c3e6cc1c7e6248ea2ff886ba9809f1a65ae2c3b (patch)
treed0f8fefe13817d4d7df0f860836c594695d046f1 /src/commands
parent66be30f7fc2f7f6378eedc8d7b219db18addbc06 (diff)
downloadredis-3c3e6cc1c7e6248ea2ff886ba9809f1a65ae2c3b.tar.gz
X[AUTO]CLAIM should skip deleted entries (#10227)
Fix #7021 #8924 #10198 # Intro Before this commit X[AUTO]CLAIM used to transfer deleted entries from one PEL to another, but reply with "nil" for every such entry (instead of the entry id). The idea (for XCLAIM) was that the caller could see this "nil", realize the entry no longer exists, and XACK it in order to remove it from PEL. The main problem with that approach is that it assumes there's a correlation between the index of the "id" arguments and the array indices, which there isn't (in case some of the input IDs to XCLAIM never existed/read): ``` 127.0.0.1:6379> XADD x 1 f1 v1 "1-0" 127.0.0.1:6379> XADD x 2 f1 v1 "2-0" 127.0.0.1:6379> XADD x 3 f1 v1 "3-0" 127.0.0.1:6379> XGROUP CREATE x grp 0 OK 127.0.0.1:6379> XREADGROUP GROUP grp Alice COUNT 2 STREAMS x > 1) 1) "x" 2) 1) 1) "1-0" 2) 1) "f1" 2) "v1" 2) 1) "2-0" 2) 1) "f1" 2) "v1" 127.0.0.1:6379> XDEL x 1 2 (integer) 2 127.0.0.1:6379> XCLAIM x grp Bob 0 0-99 1-0 1-99 2-0 1) (nil) 2) (nil) ``` # Changes Now, X[AUTO]CLAIM acts in the following way: 1. If one tries to claim a deleted entry, we delete it from the PEL we found it in (and the group PEL too). So de facto, such entry is not claimed, just cleared from PEL (since anyway it doesn't exist in the stream) 2. since we never claim deleted entries, X[AUTO]CLAIM will never return "nil" instead of an entry. 3. add a new element to XAUTOCLAIM's response (see below) # Knowing which entries were cleared from the PEL The caller may want to log any entries that were found in a PEL but deleted from the stream itself (it would suggest that there might be a bug in the application: trimming the stream while some entries were still no processed by the consumers) ## XCLAIM the set {XCLAIM input ids} - {XCLAIM returned ids} contains all the entry ids that were not claimed which means they were deleted (assuming the input contains only entries from some PEL). The user doesn't need to XACK them because XCLAIM had already deleted them from the source PEL. ## XAUTOCLAIM XAUTOCLAIM has a new element added to its reply: it's an array of all the deleted stream IDs it stumbled upon. This is somewhat of a breaking change since X[AUTO]CLAIM used to be able to reply with "nil" and now it can't... But since it was undocumented (and generally a bad idea to rely on it, as explained above) the breakage is not that bad.
Diffstat (limited to 'src/commands')
-rw-r--r--src/commands/xautoclaim.json6
1 files changed, 6 insertions, 0 deletions
diff --git a/src/commands/xautoclaim.json b/src/commands/xautoclaim.json
index b951eac29..726bf38fe 100644
--- a/src/commands/xautoclaim.json
+++ b/src/commands/xautoclaim.json
@@ -6,6 +6,12 @@
"since": "6.2.0",
"arity": -6,
"function": "xautoclaimCommand",
+ "history": [
+ [
+ "7.0.0",
+ "Added an element to the reply array, containing deleted entries the command cleared from the PEL"
+ ]
+ ],
"command_flags": [
"WRITE",
"FAST"