fix(api,ui-react): public keys search across all pages

[luizhf42]

What

The public keys search box now finds matches across all server pages instead of only the page currently in view.

Why

The React UI was already sending a filter query parameter on GET /api/sshkeys/public-keys (the same shape /devices uses), but the API handler bound only Paginator and silently dropped the filter. The page then ran a client-side .filter() over the 10 rows the server returned, so searches for a name or fingerprint living on page 2+ returned nothing.

Changes

• api: ListPublicKeys request now embeds query.Filters; the handler runs Unmarshal + ValidateFilters against a new PublicKeyFilterFields registry that restricts the filter to contains/eq/ne on name and fingerprint; the service appends Options().Match to the store call. The generic store Match already supports this without per-entity wiring, and the existing service test was updated to expect the third QueryOption.
• ui-react: usePublicKeys accepts a search param and forwards buildPublicKeyFilter(search) to the filter query param. The page debounces the input (300ms), drops the old client-side .filter() block, and resets to page 1 in the SearchField onChange handler so a new search always starts from the first page of results.

Testing

• Seed >10 keys in a namespace and search for a fragment that matches keys on page 2+. Pre-fix: zero hits while viewing page 1. Post-fix: all matches surface and the pager footer reflects the filtered total.
• Search by a fingerprint fragment — same behavior, since the registry covers both fields.
• Clear the search — the full paginated list is restored.
• Delete the last key on page > 1 while filtered — the existing empty-page back-step still works.

[github-actions]

Claude finished @luizhf42's task in 1m 3s —— View job

---

Code Review Complete

Reviewed 6 files across code quality, security, testing, Go/TypeScript patterns, and architecture — 1 issue found.

Bug: onboarding empty state shown on zero-result search

ui-react/apps/console/src/pages/public-keys/index.tsx:217 (high)

The guard if (!isLoading && publicKeys.length === 0) doesn't distinguish "no keys exist in the namespace" from "a search returned no results." Before this PR, filtering was client-side so publicKeys always held the full server page and this guard was safe. Now that filtering is server-side, a search that matches nothing returns publicKeys = [], which triggers the full "Add your first key" onboarding splash screen instead of the DataTable's "No keys matching …" message. The search field is also not rendered in the onboarding branch, so the user can't clear the search without reloading.

Fix — add && !debouncedSearch to the guard (debouncedSearch is already in scope at line 95):

- if (!isLoading && publicKeys.length === 0) {
+ if (!isLoading && publicKeys.length === 0 && !debouncedSearch) {

Fix this →

---

If you've addressed the feedback and want a new review, tag @shellhub-io/admin and a team member can trigger it.

[luizhf42]

Bug: onboarding empty state shown on zero-result search

ui-react/apps/console/src/pages/public-keys/index.tsx:217 (high)

The guard if (!isLoading && publicKeys.length === 0) doesn't distinguish "no keys exist in the namespace" from "a search returned no results." Before this PR, filtering was client-side so publicKeys always held the full server page and this guard was safe. Now that filtering is server-side, a search that matches nothing returns publicKeys = [], which triggers the full "Add your first key" onboarding splash screen instead of the DataTable's "No keys matching …" message. The search field is also not rendered in the onboarding branch, so the user can't clear the search without reloading.

FIxed. Added !debouncedSearch to the guard.

[gustavosbarreto]

/review

[github-actions]

Claude finished @gustavosbarreto's task in 5m 52s —— View job

---

Code Review Complete

Reviewed 6 files across code quality, security, testing, Go/TypeScript patterns, and architecture — no issues found.

The implementation cleanly follows established patterns:

• API: Filter handling (Unmarshal → ValidateFilters → Match) mirrors the existing device endpoint, with proper field/operator allowlisting via PublicKeyFilterFields.
• Frontend: buildPublicKeyFilter follows the same structure as buildFilter in useDevices.ts. Debounce, page reset on search, and the !debouncedSearch onboarding guard are all correct.
• Cross-repo: The pkg/api/requests/publickey.go change (embedding query.Filters in ListPublicKeys) has no impact on the cloud repo — ListPublicKeys is not used there, and PublicKeyList uses variadic QueryOption which is backward-compatible.
• Tests: Service test mocks correctly updated for the additional Match query option.

If you push additional changes and want a new review, tag @shellhub-io/admin and a team member can trigger it.

---