1. 21 Feb, 2021 1 commit
    • Huang Zw's avatar
      Client tracking tracking-redir-broken push len is 2 not 3 (#8456) · f687ac0c
      Huang Zw authored
      When redis responds with tracking-redir-broken push message (RESP3),
      it was responding with a broken protocol: an array of 3 elements, but only
      pushes 2 elements.
      
      Some bugs in the test make this pass. Read the push reply
      will consume an extra reply, because the reply length is 3, but there
      are only two elements, so the next reply will be treated as third
      element. So the test is corrected too.
      
      Other changes:
      * checkPrefixCollisionsOrReply success should return 1 instead of -1,
        this bug didn't have any implications.
      * improve client tracking tests to validate more of the response it reads.
      f687ac0c
  2. 17 Jan, 2021 1 commit
    • Yossi Gottlieb's avatar
      Add io-thread daily CI tests. (#8232) · 522d9360
      Yossi Gottlieb authored
      This adds basic coverage to IO threads by running the cluster and few selected Redis test suite tests with the IO threads enabled.
      
      Also provides some necessary additional improvements to the test suite:
      
      * Add --config to sentinel/cluster tests for arbitrary configuration.
      * Fix --tags whitelisting which was broken.
      * Add a `network` tag to some tests that are more network intensive. This is work in progress and more tests should be properly tagged in the future.
      522d9360
  3. 08 Jan, 2021 1 commit
  4. 05 Jan, 2021 1 commit
    • Oran Agra's avatar
      Fix wrong order of key/value in Lua map response (#8266) · 2017407b
      Oran Agra authored
      When a Lua script returns a map to redis (a feature which was added in
      redis 6 together with RESP3), it would have returned the value first and
      the key second.
      
      If the client was using RESP2, it was getting them out of order, and if
      the client was in RESP3, it was getting a map of value => key.
      This was happening regardless of the Lua script using redis.setresp(3)
      or not.
      
      This also affects a case where the script was returning a map which it got
      from from redis by doing something like: redis.setresp(3); return redis.call()
      
      This fix is a breaking change for redis 6.0 users who happened to rely
      on the wrong order (either ones that used redis.setresp(3), or ones that
      returned a map explicitly).
      
      This commit also includes other two changes in the tests:
      1. The test suite now handles RESP3 maps as dicts rather than nested
         lists
      2. Remove some redundant (duplicate) tests from tracking.tcl
      2017407b
  5. 27 Dec, 2020 1 commit
  6. 24 Dec, 2020 4 commits
  7. 09 Nov, 2020 1 commit
    • nitaicaro's avatar
      Extend client tracking tests (#7998) · 19c29b60
      nitaicaro authored
      Test support for the new map, null and push message types. Map objects are parsed as a list of lists of key value pairs.
      for instance: user => john password => 123
      
      will be parsed to the following TCL list:
      
      {{user john} {password 123}}
      
      Also added the following tests:
      
      Redirection still works with RESP3
      
      Able to use a RESP3 client as a redirection client
      
      No duplicate invalidation messages when turning BCAST mode on after normal tracking
      
      Server is able to evacuate enough keys when num of keys surpasses limit by more than defined initial effort
      
      Different clients using different protocols can track the same key
      
      OPTOUT tests
      
      OPTIN tests
      
      Clients can redirect to the same connection
      
      tracking-redir-broken test
      
      HELLO 3 checks
      
      Invalidation messages still work when using RESP3, with and without redirection
      
      Switching to RESP3 doesn't disturb previous tracked keys
      
      Tracking info is correct
      
      Flushall and flushdb produce invalidation messages
      
      These tests achieve 100% line coverage for tracking.c using lcov.
      19c29b60
  8. 30 Sep, 2020 1 commit
    • nitaicaro's avatar
      Fixed Tracking test “The other connection is able to get invalidations” (#7871) · 8fb89a57
      nitaicaro authored
      
      
      PROBLEM:
      
      [$rd1 read] reads invalidation messages one by one, so it's never going to see the second invalidation message produced after INCR b, whether or not it exists. Adding another read will block incase no invalidation message is produced.
      
      FIX:
      
      We switch the order of "INCR a" and "INCR b" - now "INCR b" comes first. We still only read the first invalidation message produces. If an invalidation message is wrongly produces for b - then it will be produced before that of a, since "INCR b" comes before "INCR a".
      Co-authored-by: default avatarNitai Caro <caronita@amazon.com>
      8fb89a57
  9. 14 May, 2020 1 commit
  10. 22 Apr, 2020 2 commits
  11. 14 Feb, 2020 1 commit