You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Possible bug: SearchCommands.SearchAsync() occasionally throws an IndexOutOfRange exception #448
What did you do?
We are doing a SearchCommands.SearchAsync() command on our Redis server.
What did you expect to see?
A valid search result returned by the function.
What did you see instead?
An IndexOutOfRangeException is thrown inside the SearchAsync() command. This exception is do documented anywhere as far as I am aware.
Sometimes our production environment logs a IndexOutOfRange exception when doing a SearchAsync call to our Redis server. We have had trouble reproducing it locally, so we added some temporary code to make sure it happened in the driver:
SearchResultsearchResult;try{searchResult=awaitsearchCommands.SearchAsync(indexName,queryParams);}catch(IndexOutOfRangeException){Log.Error("IndexOutOfRange occured with Query: {Query} SORTBY {SortBy} LIMIT 0 {Limit}",queryParams.QueryString,queryParams.SortBy,limit??51);throw;}
This logs the follow result: IndexOutOfRange occured with Query: "@workspaceId:{ID} @test:{false} @locationId:{LOC_ID} @sequenceId:[33483 9223372036854775807] " SORTBY "sequenceId" LIMIT 0 1001
We have already tried several ways of reproducing the error locally, by dropping indexes, corrupting indexes, invalidating keys. But nothing seems to trigger the exception. We are not familiar with the underlying driver codebase/implementation so it is only guesswork. We were also unable to find any documentation regarding this exception.
Is this a bug in the driver or are we doing something wrong on our end?
This is almost certainly a library problem; I will investigate. Sorry for the slow response on this. If you have any stacktrace info, that might help, but: I will investigate.
OK, in the absence of a stacktrace or repro, I investigated a few scenarios, see #463:
an entirely empty result from FT.SEARCH - shouldn't happen, but: improved handling
I checked all permutations of with/without scores, payloads, and content; the "with payloads, without content" combination was broken, due to a mismatch in the parser; this has been rectified
Activity
mgravell commentedon Nov 4, 2025
This is almost certainly a library problem; I will investigate. Sorry for the slow response on this. If you have any stacktrace info, that might help, but: I will investigate.
mgravell commentedon Feb 5, 2026
OK, in the absence of a stacktrace or repro, I investigated a few scenarios, see #463:
FT.SEARCH- shouldn't happen, but: improved handlingI believe #463 therefore completes this ticket