Thanks to visit codestin.com
Credit goes to github.com

Skip to content

fix(webui): show file search scope#1587

Merged
kovtcharov merged 1 commit into
amd:mainfrom
77652189:fix-file-search-scope-label
Jun 11, 2026
Merged

fix(webui): show file search scope#1587
kovtcharov merged 1 commit into
amd:mainfrom
77652189:fix-file-search-scope-label

Conversation

@77652189

Copy link
Copy Markdown
Contributor

Summary

  • show the searched filesystem scope in the file browser search results header
  • use the searched_locations already returned by the file search API
  • clear the scope label when search results are cleared or browsing resumes

Closes #581

Testing

  • npm run build

@77652189 77652189 requested a review from kovtcharov-amd as a code owner June 11, 2026 03:13
@github-actions github-actions Bot added the electron Electron app changes label Jun 11, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Review — fix(webui): show file search scope

Summary

Tidy, well-scoped fix that surfaces where a file search actually looked by rendering the searched_locations the API already returns. The wiring is correct end-to-end: backend field exists and is clamped to 10 (src/gaia/ui/routers/files.py:501), is typed in api.ts, and the new state is cleared on every reset path (load, empty query, clear button, "Back to browsing"). No backend change needed, no new dependencies, and the integration tests for searched_locations already exist (tests/integration/test_files_router.py:726). Nothing blocking — this is good to merge.

Issues

🟢 "(+N more)" count reflects the clamped list, not the true total (FileBrowser.tsx:45)

The backend already truncates to searched_locations[:10], so when a search spans more than 10 roots, formatSearchScope shows at most first (+9 more) and the tooltip lists at most 10 — silently undercounting. Purely cosmetic and arguably fine (the header is "scope," not an audit), so no change required. If you want the count to stay honest, the backend could pass the pre-clamp len(searched_locations) as a separate total_locations field. Worth a follow-up only if users will search broad scopes.

🟢 searchResults / results typed as any[] (FileBrowser.tsx:182)

Pre-existing, not introduced here — flagging only so it isn't lost: the search result rows are any[] while the API response is fully typed in searchFiles. Reusing that return type would catch field renames at compile time. Out of scope for this PR.

Strengths

  • State hygiene is completesetSearchedLocations([]) is added to every reset path (initial load, empty-query early return, clear button, back button), so the scope label can't go stale. Easy to get wrong; this got it right.
  • Reuses existing API data instead of adding an endpoint — ?? [] guards against an older backend, and the title={searchedLocations.join('\n')} tooltip exposes the full list without cluttering the header.
  • CSS is self-contained and uses existing design tokens (--text-muted, --font-mono), with min-width: 0 + ellipsis so long paths truncate cleanly rather than blowing out the layout.

Verdict

Approve. Clean, correctly-wired, no blocking issues; the two 🟢 notes are optional follow-ups, not merge gates.

@kovtcharov kovtcharov added this pull request to the merge queue Jun 11, 2026
Merged via the queue into amd:main with commit eced0da Jun 11, 2026
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

electron Electron app changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

File browser search does not indicate which directory is being searched

2 participants