fix(search): treat a whitespace-only GLOBAL_SEARCH query as no query - #5409
Merged
Conversation
decocms Bot
pushed a commit
that referenced
this pull request
Jul 30, 2026
PR: #5409 fix(search): treat a whitespace-only GLOBAL_SEARCH query as no query Bump type: patch - decocms (apps/api/package.json): 4.146.0 -> 4.146.1 Deploy-Scope: server
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
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.
Bug found while auditing the GLOBAL_SEARCH tool (offset pagination itself is already covered by open PR #5387, which this does not touch or duplicate).
The tool's own docstring promises "Empty string returns the most recently updated resources," but
GLOBAL_SEARCHpassedinput.querystraight through toThreadsStorage.list(), which doesif (options?.search)(a truthy check) before applyingilike "%<search>%". A whitespace-only query like" "is truthy, so instead of falling back to "most recent" it silently filters on a literal run of spaces intitle— almost always zero results, breaking the documented contract for any client that submits a query the user only whitespace-padded (e.g. a search box blurred after typing then deleting). The same untrimmed pass-through also meant a query like" foo "would fail to match a title of"foo"because the ILIKE pattern included the stray spaces.Fix: added a small pure
normalizeSearchQuery()helper inglobal-search.tsthat trims the query and maps an all-whitespace result toundefined(the same "no filter" valueThreadsStorage.list()already treats as "no search"), and used it in the handler instead of the rawinput.query. No change toThreadsStorage.list()itself, no change to the offset/pagination fields.Failure scenario before the fix:
GLOBAL_SEARCH({ query: " " })returns{ items: [], totalCount: 0 }for an org with recent threads, instead of the documented "most recently updated" listing.Regression test:
apps/api/src/tools/search/global-search.test.tsnow coversnormalizeSearchQuerydirectly (pure function, no DB/mocks) for empty string, whitespace-only, padded, and already-trimmed queries.Reviewer check:
bun test apps/api/src/tools/search/global-search.test.tsLocally ran:
bun run fmt,cd apps/api && bunx tsc --noEmit, and the targeted test file above — all green. Full CI covers the rest.Summary by cubic
Treats whitespace-only
GLOBAL_SEARCHqueries as no query, restoring the “most recently updated” fallback. Also trims surrounding spaces so padded queries match as expected.searchoption inThreadsStorage.list.Written for commit 1be9287. Summary will update on new commits.