Inconsistent results FT.SEARCH

[Skoucail]

We have setup a 6 node redis oss cluster (3 master, 3 slaves) with RSCoordinator loaded.

When running search queries without a return/nocontent statement we get inconsistent results. (I guess depending if the redis cluster asks the correct node). When we run the query on all master nodes at the same time (RedisInsight option), only 1 master node returns the correct answer.

[ashtul]

@Skoucail Which version of Redis/RediSearch are you using?

[Skoucail]

@ashtul The Redis/RediSearch version came with RSCoordinator and is 2.0.5

[ashtul]

@Skoucail, we need some details. Can you please give us some more details about where are the replies from and what you have expected? Also, can you share the key names you get when running with NOCONTENT flag?

[Skoucail]

@ashtul, sure I will try to give you the flow.

We are using RedisInsight CLI to test our RSCoordinator cluster. As said its a redis oss cluster (3 master, 3 slaves) with RSCoordinator loaded. Build from the v2 branch around 1.5months ago. So with RediSearch 2.0.5 loaded.

We created a index with in the schema a text field (TrackID). When searching on that index we noticed sometimes we got a result and sometimes received no results. After further investigation we noticed that when we do not specify NOCONENT or RETURN in the search query only the master node containing the hashslot answers with the result. When specifying the NOCONTENT or RETURN statement in the command. All master nodes answer with the response (as expected)

So basicly: Wrong result:

>> FT.SEARCH index:track:odata "205517490"

xx.x.x.189:6379 [master]
1) (integer) 0

xx.x.x.188:6379 [master]
1) (integer) 1
2) "track:trackid:205517490"
3)   1) "TrackID"
     2) "205517490"

xx.x.x.187:6379 [master]
1) (integer) 0

Correct result(s): 1) NOCONTENT

>> FT.SEARCH index:track:odata "205517490" NOCONTENT

xx.x.x.189:6379 [master]
1) (integer) 1
2) "track:trackid:205517490"

xx.x.x.188:6379 [master]
1) (integer) 1
2) "track:trackid:205517490"

xx.x.x.187:6379 [master]
1) (integer) 1
2) "track:trackid:205517490"

2) RETURN

>> FT.SEARCH index:track:odata "205517490" RETURN 1 TrackID

xx.x.x.187:6379 [master]
1) (integer) 1
2) "track:trackid:205517490"
3) 1) "TrackID"
   2) "205517490"

xx.x.x.189:6379 [master]
1) (integer) 1
2) "track:trackid:205517490"
3) 1) "TrackID"
   2) "205517490"

xx.x.x.188:6379 [master]
1) (integer) 1
2) "track:trackid:205517490"
3) 1) "TrackID"
   2) "205517490"

The index:

>> FT.INFO index:track:odata

 1) "index_name"
 2) "index:track:odata"
 3) "index_definition"
 4)  1) "key_type"
     2) "HASH"
     3) "prefixes"
     4) 1) "track:trackid"
     5) "language_field"
     6) "__language"
     7) "default_score"
     8) "1"
     9) "score_field"
    10) "__score"
    11) "payload_field"
    12) "__payload"
 5) "fields"
 6) 1) 1) "TrackID"
       2) "type"
       3) "TEXT"
       4) "WEIGHT"
       5) "1"
       6) "SORTABLE"
 7) "index_options"
 8) (empty list or set)
 9) "gc_stats"
10) 1) "bytes_collected"
    2) (integer) 23708621247
11) "cursor_stats"
12) 1) "global_idle"
    2) (integer) 0
    3) "global_total"
    4) (integer) 0
    5) "index_capacity"
    6) (integer) 384
    7) "index_total"
    8) (integer) 0
13) "num_docs"
14) (integer) 8824
15) "max_doc_id"
16) (integer) 295778654
17) "num_terms"
18) (integer) 166056
19) "num_records"
20) (integer) 46284250
21) "inverted_sz_mb"
22) "4.6555035724761006e+18"
23) "offset_vectors_sz_mb"
24) "4.6605918956620349e+18"
25) "doc_table_size_mb"
26) "4.6806982680515707e+18"
27) "key_table_size_mb"
28) "4.598829325884588e+18"
29) "records_per_doc_avg"
30) "5244.940592447917"
31) "bytes_per_record_avg"
32) "40.57206598917643"
33) "offsets_per_term_avg"
34) "87.088216145833329"
35) "offset_bits_per_record_avg"
36) "8"
37) "indexing"
38) (integer) 0
39) "percent_indexed"
40) "1"
41) "hash_indexing_failures"
42) (integer) 0