- 05 Mar, 2020 3 commits
-
-
Guy Benoish authored
This commit solves the following bug: 127.0.0.1:6379> XGROUP CREATE x grp $ MKSTREAM OK 127.0.0.1:6379> XADD x 666 f v "666-0" 127.0.0.1:6379> XREADGROUP GROUP grp Alice BLOCK 0 STREAMS x > 1) 1) "x" 2) 1) 1) "666-0" 2) 1) "f" 2) "v" 127.0.0.1:6379> XADD x 667 f v "667-0" 127.0.0.1:6379> XDEL x 667 (integer) 1 127.0.0.1:6379> XREADGROUP GROUP grp Alice BLOCK 0 STREAMS x > 1) 1) "x" 2) (empty array) The root cause is that we use s->last_id in streamCompareID while we should use the last *valid* ID
-
antirez authored
Fixes #6744.
-
Guy Benoish authored
This commit solves several edge cases that are related to exhausting the streamID limits: We should correctly calculate the succeeding streamID instead of blindly incrementing 'seq' This affects both XREAD and XADD. Other (unrelated) changes: Reply with a better error message when trying to add an entry to a stream that has exhausted last_id
-
- 19 Nov, 2019 4 commits
-
-
Guy Benoish authored
-
antirez authored
-
Guy Benoish authored
Calling XADD with 0-0 or 0 would result in creating an empty key and storing it in the database. Even worse, because XADD will reply with error the action will not be replicated, creating a master-replica inconsistency
-
Loris Cro authored
-
- 26 Apr, 2019 1 commit
-
-
James Rouzier authored
-
- 13 Mar, 2019 3 commits
-
-
zhaozhao.zz authored
Fix issue #5785, in case create group on a key is not stream.
-
Steve Webster authored
-
Steve Webster authored
The XCLAIM docs state the XCLAIM increments the delivery counter for messages. This PR makes the code match the documentation - which seems like the desired behaviour - whilst still allowing RETRYCOUNT to be specified manually. My understanding of the way streamPropagateXCLAIM() works is that this change will safely propagate to replicas since retry count is pulled directly from the streamNACK struct. Fixes #5194
-
- 20 Nov, 2018 3 commits
-
-
antirez authored
This commit fixes #5570. It is a similar bug to one fixed a few weeks ago and is due to the range API to be called with NULL as "end ID" parameter instead of repeating again the start ID, to be sure that we selectively issue the entry with a given ID, or we get zero returned (and we know we should emit a NULL reply).
-
antirez authored
This fixes the issue reported in #5570. This was fixed the hard way, that is, propagating more information to the lower level API about this being a request to read just the history, so that the code is simpler and less likely to regress.
-
antirez authored
-
- 05 Nov, 2018 8 commits
-
-
antirez authored
This bug had a double effect: 1. Sometimes entries may not be emitted, producing broken protocol where the array length was greater than the emitted entires, blocking the client waiting for more data. 2. Some other time the right entry was claimed, but a wrong entry was returned to the client. This fix should correct both the instances.
-
michael-grunder authored
This fixes an overflow on 32-bit systems.
-
antirez authored
-
antirez authored
-
Itamar Haber authored
-
Itamar Haber authored
-
antirez authored
-
antirez authored
-
- 17 Oct, 2018 9 commits
-
-
antirez authored
They play better with Lua scripting, otherwise Lua will see status replies as "ok" = "string" which is very odd, and actually as @oranagra reasoned in issue #5456 in the rest of the Redis code base there was no such concern as saving a few bytes when the protocol is emitted.
-
antirez authored
-
antirez authored
-
antirez authored
This avoids issues with having to replicate a command that produced errors.
-
antirez authored
-
antirez authored
Related to #5426.
-
antirez authored
Keep vanilla stream commands at toplevel, see #5426.
-
zhaozhao.zz authored
-
zhaozhao.zz authored
XSTREAM CREATE <key> <id or *> -- Create a new empty stream. XSTREAM SETID <key> <id or $> -- Set the current stream ID.
-
- 15 Oct, 2018 8 commits
-
-
antirez authored
Related to #5437.
-
antirez authored
Avoid storing the dirty value. See #5437.
-
antirez authored
See #5437 but also I updated a previous usage of the same var name.
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
zhaozhao.zz authored
Because the NACK->consumer is NULL, if idletime < minidle the NACK does not belong to any consumer, then redis will crash in XPENDING.
-
zhaozhao.zz authored
-
antirez authored
Issue #5433.
-
- 09 Oct, 2018 1 commit
-
-
antirez authored
See #5141.
-