Python: fix(python/redis): handle redisvl 0.5 API change in process_results and guard vector buffer decode

[Doondi-Ashlesh]

Summary

Fixes #13896

Two bugs in the Python Redis connector cause FT.SEARCH (collection.search(...)) to fail completely:

Bug 1 - redisvl 0.5.0 broke process_results signature

redisvl 0.5.0 changed the third parameter of process_results() from StorageType to IndexSchema. Because pyproject.toml pins redisvl ~= 0.4 (which allows 0.5.x per PEP 440), users who upgrade redisvl to 0.5.x get:

AttributeError: 'StorageType' object has no attribute 'index'

Fix: detect the active API at import time via inspect.signature. When IndexSchema is required, construct a minimal schema from the collection name and storage type before calling process_results.

Bug 2 - KeyError on missing vector field during deserialization

RedisHashsetCollection._deserialize_store_models_to_dicts calls buffer_to_array() for every vector field unconditionally. When include_vectors=False (the default for search), the vector field is absent from the result dict, raising:

KeyError: '<vector_field_name>'

Fix: skip the vector buffer decode when the field is absent from the record.

Test plan

• Run existing Redis unit tests: cd python && make test TEST_FILTERS="connectors/memory/test_redis" (no new failures)
• Manual smoke test with Redis Stack: create_collection, upsert, search with include_vectors=False (default) completes without error
• Manual smoke test with include_vectors=True still decodes vectors correctly
• Tested with both redisvl 0.4.x and 0.5.x

Signed-off-by: Doondi-Ashlesh doondiashlesh@gmail.com

[Doondi-Ashlesh]

@microsoft-github-policy-service agree

[github-actions]

Automated Code Review

Reviewers: 4 | Confidence: 89%

✓ Correctness

This PR adds backward-compatible support for the redisvl API change where process_results switched its third parameter from StorageType to IndexSchema. It uses runtime introspection to detect which API is available and constructs a minimal IndexSchema when needed. It also adds a guard for missing vector fields during deserialization. The changes are logically correct for the current usage patterns. The minimal IndexSchema (with empty fields) would cause a KeyError if normalize_vector_distance=True were ever passed to VectorQuery, but the SK code never sets that flag, so this is not a current bug — just a latent fragility.

✓ Security Reliability

This diff introduces two changes: (1) a module-level compatibility shim that uses inspect.signature to detect whether the redisvl process_results function accepts a schema parameter (new API) or a StorageType (old API), and branches accordingly at search time; (2) a defensive guard in RedisHashsetCollection._deserialize_store_models_to_dicts that checks if a vector field exists in the record before attempting buffer_to_array deserialization, preventing a KeyError when vectors are excluded from search results (include_vectors=False). Both changes are straightforward reliability improvements with no security concerns. The try/except ImportError at module level correctly handles older redisvl versions that lack IndexSchema, and the IndexSchema.from_dict call uses only trusted internal values (collection_name and storage type enum value).

✗ Test Coverage

This PR makes two defensive changes to the Redis connector: (1) a compatibility shim for the redisvl process_results API change (new versions require an IndexSchema instead of StorageType), and (2) a guard against KeyError when vector fields are absent from search results (e.g., when include_vectors=False). Neither change has any corresponding unit tests. The existing test file (test_redis_store.py) has no tests for _inner_search or for _deserialize_store_models_to_dicts with missing vector fields. Both behaviors are easily unit-testable with mocks already present in the test file.

✗ Design Approach

The diff has two changes. The vector-field presence guard (change 2) is a reasonable defensive fix. The first change — using runtime inspect.signature to detect whether process_results accepts a schema or StorageType argument — is a fragile, symptom-level workaround for an API-breaking change in redisvl. The project already pins redisvl ~= 0.4 in pyproject.toml, so the right fix is to either tighten the version constraint to the sub-version that introduced the new signature, or migrate to the new API exclusively and drop the old branch. Additionally, the try/except ImportError guard around IndexSchema is redundant: StorageType is already imported from the same redisvl.schema module unconditionally at line 24, so if redisvl is importable, IndexSchema will always be importable too, making the fallback path unreachable.

Flagged Issues

• Runtime signature introspection (inspect.signature(process_results).parameters) is used to branch between two incompatible process_results call sites. This couples SK permanently to detecting a transient redisvl API break instead of expressing the version requirement explicitly. The proper fix is to tighten the redisvl ~= 0.4 pin to the sub-version where process_results gained the schema parameter (and use only that API path), or cap the upper bound and keep only the old path. Signature sniffing will silently do the wrong thing if redisvl's signature changes again.

Suggestions

• Add unit tests for both new code paths: (1) a test for _deserialize_store_models_to_dicts with a record missing the vector field key, verifying no KeyError is raised; (2) a parametrized test for _inner_search that patches _PROCESS_RESULTS_USES_SCHEMA to True/False and asserts the correct process_results call signature is used.

---

Automated review by Doondi-Ashlesh's agents