If index 3 is not a list, assume Redis Enterprise and return index 4 as slowlog command

[ian28223]

Pull Request check-list

Please make sure to review and check all of these items:

• Does $ tox pass with this change (including linting)?
• Does travis tests pass with this change (enable it first in your forked repo and wait for the travis build to finish)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.

Description of change

Some redis instances, Redislabs for example, return slowlog entries with the commands at item[4] instead of item[3].

command is always a list; return item[4] if item[3] is not a list.

Example:

 1) 1) (integer) 4764
    2) (integer) 1592198570
    3) (integer) 3
    4)
    5) 1) "LPUSH"
       2) "testkey2"
       3) "0.7346415842722306"
 2) 1) (integer) 4763
    2) (integer) 1592198570
    3) (integer) 3
    4)
    5) 1) "LPUSH"
       2) "testkey2"
       3) "0.6277650251277609"
 3) 1) (integer) 4762
    2) (integer) 1592198570
    3) (integer) 4
    4)
    5) 1) "LPUSH"
       2) "testkey2"
       3) "0.7646428397907798"
 4) 1) (integer) 4761
    2) (integer) 1592198570
    3) (integer) 3
    4)
    5) 1) "LPUSH"
       2) "testkey2"
       3) "0.7501418278370815"

[andymccurdy]

@ian28223 The command is never the last item in Redis server 4.0 or later. I'm not sure what extra entires (if any) Redis Labs returns, but this change won't work for the open source version.

[RoeyPrat]

Hi @ian28223,
Thank you for bringing this up.

It seems Redis Enterprise injects another entry at index [3], which has the complexity info (i.e. the value of N in case the command has an O(N) complexity).
Whatever the schema of this response is, we need it to be standardized and documented in order to introduce it to redis-py, otherwise it might change it a way we can't predict.
I'll reach out to the relevant developers in Redislabs, to get the Redis Enterprise slowlog get schema standardized and documented, but this is outside the scope of redis-py.

For now, I'm creating a new issue to support the Client IP address and port and Client name added in v4 of Redis OSS
#1374.

[oranagra]

I think the right way to work around this incompatibility of RE (until it gets fixed), is to look at the entry at [3] and see if it's an array or a string.
The command arguments will always be a multi-bulk, so if we see that [3] is an array, we can assume this is the OSS redis format, and if we see [3] is a string, we can assume that's RE complexity field, and shift all the fields forward by one, i.e. the command is at [4], and the client details at [5] and [6] (instead of [4], [5] like in OSS redis)

[hithwen]

@oranagra

I think the right way to work around this incompatibility of RE (until it gets fixed), is to look at the entry at [3] and see if it's an array or a string.

I think in case of Redis Enterprise the field is an int as @ RoeyPrat said

It seems Redis Enterprise injects another entry at index [3], which has the complexity info (i.e. the value of N in case the command has an O(N) complexity).

In either case checking if it's a string might still be the solution

[oranagra]

by [3] i meant 0 based. the output posted above is from redis-cli which is 1 based.
in that example the field is empty, but had this response been from standard redis, it would have been the arguments array.

[ian28223]

I've applied the suggestion which is to return index 4 as the command if index 3 is not a list.

[hithwen]

Seems the build has failed due to a pull limit. Is there a way to rerun it?

[andymccurdy]

@ian28223 Nit-picky, but can you fix the flake8 error please? Looks like the line is too long now.

[andymccurdy]

The error that Travis is reporting doesn't seem related to this PR. It looks like a test case that mixes mocks and threading is failing on PyPy3 suddenly. Not sure why off the top of my head, but I'll look into it this afternoon.

[ian28223]

The error that Travis is reporting doesn't seem related to this PR. It looks like a test case that mixes mocks and threading is failing on PyPy3 suddenly. Not sure why off the top of my head, but I'll look into it this afternoon.

Any updates as to why the unrelated test is failing?

[codecov-commenter]

Codecov Report

Merging #1352 (ab7b09b) into master (15dafb1) will increase coverage by 0.68%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1352      +/-   ##
==========================================
+ Coverage   85.90%   86.58%   +0.68%     
==========================================
  Files           6        7       +1     
  Lines        2894     2914      +20     
==========================================
+ Hits         2486     2523      +37     
+ Misses        408      391      -17     

Impacted Files	Coverage Δ
redis/client.py	87.02% <100.00%> (+1.09%)	⬆️
redis/lock.py	100.00% <0.00%> (ø)
redis/__init__.py	83.33% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7e466f7...ab7b09b. Read the comment docs.

[hithwen]

Seems builds are green now. Can we get this in?

[andymccurdy]

@ian28223 Can you rebase your PR off of the latest master? Thanks.

[hithwen]

Seems an unrelated test is failing after rebasing?

[andymccurdy]

I haven't tracked down the PyPy error yet, but it's definitely not related to this change. Thanks for putting this together.

[ian28223]

I haven't tracked down the PyPy error yet, but it's definitely not related to this change. Thanks for putting this together.

Much appreciated for the merge! Any chance we can get a new release including it? A 3.5.4 perchance?

[hithwen]

When is next release planed? It's been a year since the latest