test: apply Redis server flags via compose command, not REDIS_ARGS

[nkanu17]

Fixes #658

Problem

tests/docker-compose.yml passed Redis server flags through the REDIS_ARGS environment variable. REDIS_ARGS is a redis-stack image convention: its entrypoint reads the variable and appends it to the server command line. The official docker.io/library/redis image that this compose file uses never reads it, so --save '', --appendonly no, and --search-workers were all silently discarded.

The practical effect was that the --search-workers 0 pin, added to keep newer Redis images on the same query execution model as the pinned ones, had never taken effect on any image.

This is test infrastructure only. No shipped redisvl code is affected, so no released version carries a defect from this.

Fix

The flags are now passed as real server arguments via a compose command: entry, with the ${REDIS_SEARCH_WORKERS:-0} parameterization preserved. The accompanying comment was rewritten to explain the actual mechanism (the official image ignores REDIS_ARGS) and no longer asserts the FT.SEARCH nil-field race as established fact, for the reason in the next section.

Exec (list) form turned out to express --save '' correctly, so no shell-form fallback was needed. docker inspect -f '{{json .Args}}' confirms the argv reaching the server:

["redis-server","--save","","--appendonly","no","--search-workers","0"]

Verification

Containers were started from this compose file and inspected directly. On redis:latest (8.10.0):

CONFIG GET search-workers  ->  0        (was 14 before this change)
CONFIG GET save            ->  ""       (zero-length string, no save points)
CONFIG GET appendonly      ->  no

The same three checks pass on redis:8.4 (8.4.5) and redis:8.2 (8.2.8), where search-workers 0 is already the default so the pin is a no-op, and both containers start normally. --search-workers is accepted on all three images, so no version gating is needed.

Parameterization still works: REDIS_SEARCH_WORKERS=4 yields CONFIG GET search-workers -> 4 on both redis:latest and redis:8.4, with save and appendonly unchanged.

Integration tests exercising the testcontainers DockerCompose fixture that drives this file:

• tests/integration/test_search_index.py: 46 passed
• tests/integration/test_hybrid.py: 12 passed, 2 skipped

Why this matters: it fixes the flaky redis:latest jobs

The comment being replaced attributed flaky redis:latest runs to the Redis 8.8 change that enables a multithreaded RediSearch worker pool. That attribution is correct, and because REDIS_ARGS was ignored, search-workers has been at the image default on every redis:latest CI job, so the intended mitigation was never in effect.

Reproduced with 8 concurrent threads each creating an index, loading 3 documents, and querying immediately expecting all 3, 60 iterations per thread (480 total), against redis:latest (8.10.0):

configuration	shortfalls	documents seen at first query
search-workers 14 (image default), 1 CPU	17/480	0, 1, or 2 instead of 3
search-workers 14 (image default), unconstrained CPU	17/480	0, 1, or 2 instead of 3
search-workers 0	0/480	always 3

The partial-result distribution matches the observed CI failures: zero documents (test_hybrid.py returning 0 of 7) and 1 or 2 of 3 (test_unf_noindex_integration).

The writes are not lost. Across 30 shortfall events, all 3 hashes were already in the keyspace every time, and the index caught up in every case within 0.8 to 2.6 ms (median 1.6 ms). So FT.SEARCH briefly loses read-your-writes consistency under concurrent write and query load, and search-workers 0 eliminates it.

A single-threaded probe against an idle server shows no shortfall at all, which is why an earlier attempt of mine failed to reproduce this. Concurrency is required to surface it.

This is server behavior and also affects library users who load and then immediately query under concurrency. That is tracked separately for documentation and is not addressed by this PR.

[Copilot]

Pull request overview

Updates the test Docker Compose configuration for Redis so that Redis server flags are actually applied when using the official docker.io/library/redis image (which ignores the REDIS_ARGS environment variable). This aligns the test container’s runtime configuration with what the compose file declares, especially for --search-workers.

Changes:

• Replace REDIS_ARGS environment-based flag passing with a real Compose command: argv list.
• Preserve ${REDIS_SEARCH_WORKERS:-0} parameterization while ensuring --save "" and --appendonly no are applied.
• Rewrite the inline comment to accurately document the mechanism and avoid asserting an unproven CI flakiness root cause.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[nkanu17]

Closing as a duplicate of #653, which already contains this fix and predates it by over a week.

The functional change is identical: same exec-form command: with the same seven arguments and the same ${REDIS_SEARCH_WORKERS:-0} parameterization. A diff of the two branches on tests/docker-compose.yml shows only comment wording, and #653's comment is the better one, noting the 8.8.0 default of 12 and documenting the override for reproducing the race locally.

My verification is recorded on #653 rather than duplicated here: search-workers 0 applied on redis:latest (8.10.0), CONFIG GET save returning an empty string so exec form does express --save """ correctly, appendonly no, all confirmed on redis:8.4 and redis:8.2 too, and REDIS_SEARCH_WORKERS=4` overriding as expected.

Issue #658 is likewise a duplicate of a problem already diagnosed in #653 and can be closed with it.