SearchIndex.drop_keys does not validate cluster hash-tag co-location (inconsistent with drop_documents)
维护者通常 5 天内回复
还没有人认领这个 Issue。
- #614 来自 @algojogacor —— 已关闭，未合并
评估
调研方向
从 redisvl/index/index.py 中的 SearchIndex.drop_keys（约第 826 行）开始，将其与 drop_documents（约第 840 行）进行比较，包括现有的 RedisCluster 哈希标签验证。确保两个方法具有完全一致的集群行为：无效的跨槽 key 必须在调用 delete 之前引发所述的 ValueError。
由索引模型根据 Issue 内容生成。
描述
Current behavior
SearchIndex.drop_documents (redisvl/index/index.py:840) explicitly validates that all keys share a hash tag before calling delete:
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.")
return self._redis_client.delete(*keys)
SearchIndex.drop_keys (redisvl/index/index.py:826) does not. On a clustered Redis Enterprise database, a multi-key DEL whose keys do not all hash to the same slot raises CROSSSLOT from the server — but only some redis-py client modes surface this cleanly. In others the call partially succeeds or fails opaquely.
Proposed change
Apply the same hash-tag check in drop_keys that drop_documents already applies, or factor the check into a shared helper called by both. Behavior on cluster should be identical between the two methods.
Why this surfaces
SemanticCache.drop() uses drop_keys under the hood for the keys= argument path and uses drop_documents for the ids= argument path. The two argument paths therefore behave differently on cluster, which is a footgun for customers building invalidation jobs that take whichever shape comes from their query results.
Notes
Surfaced while writing a scoped semantic caching architecture spec.
- 主要语言
- Python
- 星标
- 431
- 派生
- 107
- 平均合并
- 5 天 17 小时
- 30 天内合并 PR
- 16
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
redis/redis-vl-python 的其他 Issue
-
Add Python 3.15 support可能已有人在做 @vishal-bala 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 65/100
redis/redis-vl-python#757 · 1 条评论 · 1 个 reaction ·
维护者通常 5 天内回复
-
documentation
难度 1/5 1 小时以内 新手友好度 62/100
redis/redis-vl-python#300 ·
维护者通常 5 天内回复
-
Migration executor cannot read an FT.AGGREGATE cursor over a RESP3 connection, raising KeyError可能已有人在做 @Kuang-xianxin 于 41 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 68/100
redis/redis-vl-python#714 ·
维护者通常 5 天内回复
-
Migration readiness checks read FT.INFO with string keys, so under RESP3 they always report a healthy index可能已有人在做 @Kuang-xianxin 于 41 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 74/100
redis/redis-vl-python#713 ·
维护者通常 5 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
redis/redis-vl-python#684 ·
维护者通常 5 天内回复
查看 redis/redis-vl-python 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 64/100
aws-samples/sample-per-model-bedrock#295 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 76/100
pyrevitlabs/pyRevit#3792 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 69/100
zephyrproject-rtos/reqmgmt#177 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
polarsource/polar#15580 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 85/100
521xueweihan/HelloGitHub#4011 ·