fix(extensions): tolerate non-string tags in catalog search#3746
Open
Noor-ul-ain001 wants to merge 2 commits into
Open
fix(extensions): tolerate non-string tags in catalog search#3746Noor-ul-ain001 wants to merge 2 commits into
Noor-ul-ain001 wants to merge 2 commits into
Conversation
ExtensionCatalog.search() assumed catalog `tags` were always strings: the tag filter called `t.lower()` and the query path did `" ".join([...] + tags)`. Extension catalog JSON is user-editable, so a hand-authored `tags: [1, 2]` crashed search with AttributeError (tag filter) or TypeError (query join). Coerce defensively by filtering to `isinstance(t, str)` and guarding the tags value as a list, matching the reference-correct sibling in integrations/catalog.py. Non-string tags are now skipped rather than raising. Adds a regression test driving search(tag=...) and search(query=...) against a catalog with mixed string/int tags; both fail pre-fix. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The same ExtensionCatalog.search() method had two more string
assumptions on user-editable catalog fields: the author filter called
`ext_data.get("author", "").lower()` (AttributeError on a numeric
author) and the query searchable-text joined `name`/`description`
uncoerced (TypeError on a numeric name). Coerce both defensively,
matching the reference-correct integrations/catalog.py::search.
Extends the regression test with non-string author/name coverage;
fails pre-fix with AttributeError at the author filter.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@
Summary
ExtensionCatalog.search()assumed catalogtagsentries were always strings:tag.lower() not in [t.lower() for t in ext_data.get("tags", [])]" ".join([...] + ext_data.get("tags", []))Extension catalog JSON is user-editable, so a hand-authored
tags: [1, 2]crashes search:search(tag=...)→AttributeError: int object has no attribute lowersearch(query=...)→TypeError: sequence item N: expected str instance, int foundFix
Coerce defensively: guard the
tagsvalue as a list and filter toisinstance(t, str), matching the reference-correct sibling inintegrations/catalog.py::search. Non-string tags are skipped rather than crashing. This is the same bug class fixed for presets in #3743.Testing
Adds
test_search_tolerates_non_string_tags, which drives bothsearch(tag=...)andsearch(query=...)against a catalog with mixed string/int tags. It fails pre-fix (AttributeErrorat the tag filter) and passes after. All existingtest_search*tests remain green.🤖 Generated with Claude Code
@