fix: add cluster hash-tag validation to SearchIndex.drop_keys

[algojogacor]

Summary

Fixes #601 — SearchIndex.drop_keys should validate cluster hash-tag co-location, consistent with drop_documents.

Root Cause

drop_keys (redisvl/index/index.py:826) called self._redis_client.delete(*keys) on a RedisCluster without checking whether all keys share a hash tag. On clustered Redis Enterprise, multi-key DEL across different hash slots raises CROSSSLOT errors or silently fails depending on the redis-py client mode.

Meanwhile, drop_documents (line 860-866) already had a guard:

if isinstance(self._redis_client, RedisCluster) and not _keys_share_hash_tag(keys):
    raise ValueError("All keys must share a hash tag when using Redis Cluster.")

This inconsistency meant SemanticCache.drop() behaved differently depending on whether callers used the keys= path (via drop_keys) or the ids= path (via drop_documents).

Fix

Added the same isinstance(self._redis_client, RedisCluster) and _keys_share_hash_tag() guard to drop_keys, raising the same ValueError with the same message.

Changes

• redisvl/index/index.py (+7): Added cluster hash-tag validation in drop_keys method

Testing

• The guard is identical to the one already used and tested in drop_documents
• Single-key calls (non-list path) are unaffected — hash-tag check only applies to multi-key list path
• Non-cluster Redis clients are unaffected — the isinstance check gates the validation

---

Note

Low Risk
Small, localized guard mirroring existing drop_documents behavior; no changes to standalone Redis or single-key deletes.

Overview
SearchIndex.drop_keys now rejects multi-key deletes on RedisCluster when the keys do not share a hash tag, using the same _keys_share_hash_tag check and ValueError message as drop_documents.

This avoids cross-slot DEL failures (or inconsistent client behavior) when callers pass a list of raw Redis keys, and aligns cache/index deletion paths that use drop_keys with those that use drop_documents. Single-key deletes and non-cluster clients are unchanged; validation runs only for list inputs on a cluster client.

^{Reviewed by Cursor Bugbot for commit 79a77cf. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jit-ci]

Hi, I’m Jit, a friendly security platform designed to help developers build secure applications from day zero with an MVS (Minimal viable security) mindset.

In case there are security findings, they will be communicated to you as a comment inside the PR.

Hope you’ll enjoy using Jit.

Questions? Comments? Want to learn more? Get in touch with us.

[vishal-bala]

Hi, thanks for your contribution - please rebase onto main to get the latest changes.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 79a77cf. Configure here.}

[cursor]

Async drop_keys skips hash-tag check

Medium Severity

The new cluster hash-tag guard is only applied on sync drop_keys. AsyncSearchIndex.drop_keys still issues a multi-key delete without that check, so cluster callers of SemanticCache.adrop() can still hit CROSSSLOT while the matching sync path raises ValueError.

Additional Locations (1)

• redisvl/index/index.py#L1795-L1797

 

^{Reviewed by Cursor Bugbot for commit 79a77cf. Configure here.}