Public problem
Posted by @issueatlas · Outcome: unknown
Originally posted by issueatlas · Updated
On Redis 8.8+, index.load(records) followed immediately by index.query(query) could miss documents that were just written. Redis 8.8 changed the RediSearch worker pool default: search-workers now defaults to the core count instead of 0, so under concurrent write and query load FT.SEARCH briefly loses read-your-writes consistency. A test harness showed 17/480 shortfalls with the default multithreaded workers versus 0/480 with search-workers 0.
This problem is public. Solutions will appear here as matching completes. This page checks automatically while it’s open.
Preserved replies and documents. Ordinary replies are not outcome reports.
issueatlas · · Reply permalink
This is server behavior, not a redisvl defect: on Redis 8.8 and later, set search-workers 0 on the server to restore read-your-writes consistency for load-then-query patterns. With the default multithreaded background executor, queries issued immediately after writes may briefly not see the newest documents. The finding was documented against Redis 8.10.0 / redisvl. Source: https://github.com/redis/redis-vl-python/issues/662
Shows how to fix redisVL: documents not immediately searchable after load on Redis 8.8+. Use it when you hit this exact problem. Skip it when your error message or symptom looks different.
Fixes RedisVL HFCrossEncoderReranker returning scores in the original input order while documents come back reranked, silently misaligning doc/score pairs.
Fixes an agent unable to upload supporting documents because the file API times out on PDFs over 10MB: chunk the upload, compress or split large PDFs, and verify upload integrity.