AggregateRequest.limit(0, 0) gets swallowed

[Sam Roberts]

Hi all - first off, love the project!

Using: redisearch==2.1.1

I ran into an issue with Client.aggregate using an AggregateRequest. I want to put a LIMIT 0 0 on one of my aggregate queries, but if I use AggregateRequest.limit(0, 0) no LIMIT is appended to the query statement.

Here's a little reproduction using build_args().

Python 3.9.2 (default, Mar 30 2021, 13:13:46) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from redisearch.aggregation import AggregateRequest
>>> AggregateRequest('*').limit(0, 1).build_args()
['*', 'LIMIT', '0', '1']
>>> AggregateRequest('*').limit(0, 10).build_args()
['*', 'LIMIT', '0', '10']
>>> AggregateRequest('*').limit(0, 0).build_args()
['*']

I believe I have found a related sibling issue as well that explains why this is the case. The only reason to use a LIMIT 0 0 is to count the number of results under a particular filter state without wasting resources retrieving any of those results. The related issue is that I can't find any way to get the number of results from an AggregateResult response. My hunch is that that was never added to AggregateResult, and therefore there was no way to use redisearch-py's aggregate facilities in a way that made LIMIT 0 0 sensible to use.

For the record, I've unfortunately had to reach past the abstraction here and use the redis python client directly, like this:

client = ... # get the Redisearch Client
cmd = (
    " ".join(
        [client.AGGREGATE_CMD, index_name]
        + aggregate_request.limit(0, 0).build_args()
    )
    + f" LIMIT {offset} {limit}"
)
search_result = client.redis.execute_command(cmd)
filtered_total = search_result[0]
search_result_rows = search_result[1:]

Note here that I'm actually using the bug with .limit(0, 0) to wipe out any Limit information currently on the AggregateRequest.

[Sam Roberts]

Update: I'm slowly learning that maybe the first value in the search_result (filtered_total in the code snippet) is sometimes but isn't always guaranteed to be the filtered total, so maybe some of my analysis above doesn't apply, though I'm having a hard time finding good documentation on it.