1. 23 Apr, 2020 1 commit
  2. 22 Apr, 2020 1 commit
  3. 21 Apr, 2020 1 commit
  4. 17 Apr, 2020 1 commit
  5. 10 Apr, 2020 1 commit
  6. 30 Mar, 2020 1 commit
    • Guy Benoish's avatar
      streamReplyWithRange: Redundant XSETIDs to replica · 12d74791
      Guy Benoish authored
      propagate_last_id is declared outside of the loop but used
      only from within the loop. Once it's '1' it will never go
      back to '0' and will replicate XSETID even for IDs that
      don't actually change the last_id.
      While not a serious bug (XSETID always used group->last_id
      so there's no risk), it does causes redundant traffic
      between master and its replicas
      12d74791
  7. 26 Mar, 2020 2 commits
  8. 23 Feb, 2020 1 commit
  9. 19 Feb, 2020 1 commit
  10. 08 Jan, 2020 1 commit
  11. 30 Dec, 2019 1 commit
    • Guy Benoish's avatar
      Blocking XREAD[GROUP] should always reply with valid data (or timeout) · a351e74f
      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
      a351e74f
  12. 26 Dec, 2019 1 commit
    • Guy Benoish's avatar
      Stream: Handle streamID-related edge cases · 1f75ce30
      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
      1f75ce30
  13. 18 Dec, 2019 1 commit
  14. 19 Nov, 2019 1 commit
  15. 13 Nov, 2019 1 commit
    • Guy Benoish's avatar
      XADD with ID 0-0 stores an empty key · 4a12047c
      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
      4a12047c
  16. 06 Nov, 2019 1 commit
    • Guy Benoish's avatar
      Support streams in general module API functions · 1833d008
      Guy Benoish authored
      Fixes GitHub issue #6492
      Added stream support in RM_KeyType and RM_ValueLength.
      Also moduleDelKeyIfEmpty was updated, even though it has
      no effect now (It will be relevant when stream type direct
      API will be coded - i.e. RM_StreamAdd)
      1833d008
  17. 04 Nov, 2019 2 commits
  18. 10 Oct, 2019 1 commit
  19. 11 Apr, 2019 1 commit
  20. 12 Mar, 2019 1 commit
  21. 08 Mar, 2019 1 commit
    • Steve Webster's avatar
      Increment delivery counter on XCLAIM unless RETRYCOUNT specified · f1e7df4b
      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
      f1e7df4b
  22. 16 Jan, 2019 1 commit
  23. 09 Jan, 2019 1 commit
  24. 19 Nov, 2018 3 commits
  25. 05 Nov, 2018 2 commits
    • antirez's avatar
      Fix XCLAIM missing entry bug. · 6ba50784
      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.
      6ba50784
    • antirez's avatar
      Improve streamReplyWithRange() top comment. · e7c579e1
      antirez authored
      e7c579e1
  26. 03 Nov, 2018 1 commit
  27. 31 Oct, 2018 1 commit
  28. 25 Oct, 2018 2 commits
  29. 24 Oct, 2018 1 commit
  30. 17 Oct, 2018 5 commits