RI-8316 Match key type when finding indexes for a key#6200
Conversation
Code Coverage - Backend unit tests
Test suite run success3692 tests passing in 321 suites. Report generated by 🧪jest coverage report action from 5409235 |
The key-indexes endpoint matched indexes by prefix only, so a JSON key matched FT.CREATE ... ON HASH indexes with the same prefix and the key details panel wrongly offered "View index". Resolve the key's type via TYPE and require it to match the index definition's key_type; keys of unsearchable types return no indexes. Fixes #RI-8316 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
dantovska
force-pushed
the
be/bugfix/RI-8316/match-key-type-in-key-indexes
branch
from
48eaa9d to
5409235
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5409235426
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (!indexKeyType) { | ||
| return plainToInstance(KeyIndexesResponse, { indexes: [] }); |
There was a problem hiding this comment.
When the requested key does not currently exist, TYPE returns none, so this early return skips FT._LIST/FT.INFO and reports no indexes. The existing POST /redisearch/key-indexes integration setup passes ${TEST_SEARCH_HASH_KEY_PREFIX_1}1 while generateRedisearchIndexes only creates no-prefix HASH indexes, so that endpoint now returns [] instead of TEST_SEARCH_HASH_INDEX_1 for the tested key-name lookup scenario.
Useful? React with 👍 / 👎.
1 participant
What
The
redisearch/key-indexesendpoint (behind "View index" / "Make searchable" in the key details panel) matched indexes by prefix only — the index definition'skey_typewas returned but never compared. A JSON key likefoo:bartherefore matched anFT.CREATE … ON HASH PREFIX 1 "foo:"index and the panel showed "View index" for an index that will never cover that key.The service now resolves the key's type with
TYPEand only returns indexes whosekey_typematches (hash→HASH,ReJSON-RL→JSON); keys of unsearchable types short-circuit to no matches. Empty-prefix ("match all") indexes also respect the key type now. No API shape change.Also fixes the cluster-dedup unit test, which mocked
FT.INFOon the wrong client and only passed because an undefined reply degraded to an empty (match-all) definition — the new type check exposed it.Testing
key-indexes.service.spec.ts— existing cases updated to mockTYPE, plus new cases: HASH index vs JSON key → no match, empty-prefix index respects key type, unsupported key type returns empty without listing indexes (33 backend redisearch tests pass).FT.CREATE idx ON HASH PREFIX 1 "x:"+HSET x:h …+JSON.SET x:j …→ key-indexes returns the index forx:hand nothing forx:j(previously both matched).Closes #RI-8316
🤖 Generated with Claude Code
Note
Low Risk
Scoped browser API behavior fix with no response shape change; adds one TYPE round-trip per lookup for searchable key types only.
Overview
getKeyIndexesno longer treats prefix overlap as enough to link a key to a RediSearch index. It runsTYPEon the key first, mapshash/ReJSON-RLto the index definition’sHASH/JSON, and only keeps indexes whosekey_typematches. Prefix rules are unchanged, including empty-prefix indexes, but those now also require the same type. Keys that aren’t HASH or JSON return an empty list without callingFT._LIST.Unit tests mock
TYPEvia a shared helper, add cases for type mismatch and unsupported types, and fix cluster dedup by stubbingFT.INFOon the shard client that actually runs it.Reviewed by Cursor Bugbot for commit 5409235. Bugbot is set up for automated code reviews on this repo. Configure here.