Migration readiness checks read FT.INFO with string keys, so under RESP3 they always report a healthy index

Chiusa
  • Qualcosa non va?
#713 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 5 giorni

@Kuang-xianxin ci sta già lavorando.

Dal 6/9/2026.

  • #730 di @Kuang-xianxin — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
74/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python, redis
Ambito
databases

Direzione di ricerca

Inizia con i controlli di prontezza in redisvl/migration/executor.py:254 e con la logica corrispondente in redisvl/migration/async_executor.py, quindi confronta la loro gestione grezza di FT.INFO con SearchIndex.info() e planner.py:216. Il lavoro è completato quando le risposte RESP3 riportano i valori effettivi di failure e indexing, in modo che gli indici con errori utilizzino il fallback SCAN esistente sia nei percorsi di migrazione sincroni sia in quelli asincroni.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

On a RESP3 connection the migration executor's readiness check concludes that every index is fully built with zero indexing failures, whatever the server actually reports. It therefore skips the SCAN fallback that exists precisely to avoid missing documents. This is a silent wrong answer rather than a crash, which is what makes it worth fixing ahead of louder failures: the check passes, the migration proceeds, and documents the server could not index are never enumerated.

Reproduction

Measured on Redis 8.4.6 with redis-py 8.1.0, RedisVL at edcc78e. The index covers five hashes: three index cleanly, and two carry a malformed vector blob, so the server reports hash_indexing_failures of 2.

=== RESP2 ===
  actual hash_indexing_failures on server: 2
  info.get("hash_indexing_failures", 0) as the executor reads it: 2
  keys enumerated (5): ['f:bad0', 'f:bad1', 'f:ok0', 'f:ok1', 'f:ok2']

=== RESP3 ===
  actual hash_indexing_failures on server: 2
  info.get("hash_indexing_failures", 0) as the executor reads it: 0
  keys enumerated: none, raises KeyError: slice(1, None, None)

Under RESP2 the guard fires, logs Index 'fail_idx' has 2 indexing failures. Using SCAN for complete enumeration., and enumerates all five keys including the two that failed to index. Under RESP3 the guard reads zero failures, skips SCAN, and hands control to the aggregate path.

Cause

FT.INFO comes back with bytes keys under RESP3. Measured on both redis-py 6.3.0 and 8.1.0:

[b'index_name', b'index_options', b'index_definition', b'attributes', b'num_docs', ...]

redisvl/migration/executor.py:254 reads that dict with string keys:

failures = int(info.get("hash_indexing_failures", 0) or 0)
percent_indexed = float(info.get("percent_indexed", 1.0) or 1.0)

Both lookups miss, so both defaults apply. The defaults were chosen to mean "nothing is wrong", so the guard concludes the index is complete and failure-free and takes the fast path. redisvl/migration/async_executor.py:107 and :108 are the same code, and async_executor.py repeats the shape around line 222, where _enumerate_with_scan reads prefixes out of the same raw info reply.

The proximate cause is that these sites call client.ft(index_name).info() directly rather than going through RedisVL's own wrapper. SearchIndex._info in redisvl/index/index.py passes the reply through convert_bytes, so SearchIndex.info() returns string keys and the right value on the same RESP3 client:

>>> index.info()["hash_indexing_failures"]
2

Measured on the same build and the same index that produced the zero above. The planner already uses that wrapper, since redisvl/migration/planner.py:216 calls index.info(), so its readiness checks at lines 157 and 174 read correctly. Only the executor's raw calls are wrong, in both the sync and async variants.

Suggested fix

Route the executor's readiness checks through convert_bytes, or through SearchIndex.info(), so that the executor and the planner read FT.INFO the same way. Reading one field under two conventions in two files of the same package is the underlying problem, and normalising at a single point fixes every call site at once. The defaults are worth revisiting too: a lookup that misses should not be indistinguishable from a server reporting good news.

Related

The path this bug hands control to is itself broken on RESP3: see #714, where the aggregate cursor read raises KeyError, which is the exception shown in the reproduction above. The two cannot both surface under RESP2, because a correct readiness check diverts to SCAN before the aggregate code runs. Under RESP3 this bug removes the guard and #714 then raises.

Lingua principale
Python
Stelle
433
Fork
120
Merge medio
8g 1h
PR unite (30g)
29

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di redis/redis-vl-python

Tutte le issue di redis/redis-vl-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.