fix(users): resolve user detail via frontierService.getUser instead of searchUsers

[Shreyag02]

Summary

Replaces the searchUsers RPC with frontierService.getUser for resolving a single user by ID in the user-detail view.

searchUsers does a search-string match, which failed to resolve some IDs and caused 404s when the user-detail page was reached via the audit-logs sidepanel actor link. getUser fetches directly by ID, fixing both the audit-logs and Users-page detail flows (they share the same component).

Changes

• user-details.tsx: UserDetailsByUserId now queries FrontierServiceQueries.getUser with { id } and reads data?.user, instead of searchUsers with { query: {search: userId } } / data?.users?.[0].
• block-user.tsx: Updated the block/unblock optimistic cache update to target the getUser query key ({ id }, single user) so state changes still reflect instantly; removed the now-unused AdminServiceQueries import.

Technical Details

• Both the audit-logs actor link (/users/:id) and the Users-page detail view route through the same UserDetailsByUserId component, so one change coversboth scopes.
• The users list (list.tsx) intentionally keeps searchUsers — it's a paginated, filterable search query that getUser (single-user, by-ID) cannot replace.
• The optimistic-update key in block-user.tsx matches the getUser query exactly (same schema, { id } input, finite cardinality, transport), preserving the prior instant-feedback behavior.

Test Plan

• Manual testing completed — audit-logs sidepanel actor link resolves to the user-detail page (no 404); block/unblock reflects immediately
• Build and type checking passes — tsc --noEmit clean for both files

SQL Safety (if your PR touches *_repository.go or goqu.*)

N/A

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
frontier	Ready	Preview, Comment	Jul 8, 2026 11:13am

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 73c2c617-eac1-418d-9ef9-1aa8c4b6eaa2

📥 Commits

Reviewing files that changed from the base of the PR and between 545ee21 and 726f43c.

📒 Files selected for processing (2)

• web/sdk/admin/views/users/details/security/block-user.tsx
• web/sdk/admin/views/users/details/user-details.tsx

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes
  • User details now load from the correct user record, improving reliability when viewing an individual user.
  • Blocking or unblocking a user now updates the displayed status immediately and more accurately in the UI.

Walkthrough

User details fetching and optimistic cache updates were migrated from an admin search-based query to a direct getUser query. user-details.tsx now fetches via FrontierServiceQueries.getUser({ id }) and reads data?.user, while block-user.tsx updates the corresponding getUser cache entry instead of search results.

Changes

User query migration

Layer / File(s)	Summary
Fetch user details via getUser web/sdk/admin/views/users/details/user-details.tsx	Query switched from AdminServiceQueries.searchUsers to FrontierServiceQueries.getUser with { id: userId }, and user is read from data?.user instead of data?.users?.[0].
Optimistic cache update for getUser web/sdk/admin/views/users/details/security/block-user.tsx	Introduces GetUserQueryData type and updates optimisticUpdateState to target the FrontierServiceQueries.getUser cache entry, setting user.state directly on cached data.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coveralls]

Coverage Report for CI Build 28938255444

Coverage remained the same at 44.879%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	37621
Covered Lines:	16884
Line Coverage:	44.88%
Coverage Strength:	12.49 hits per line

---

💛 - Coveralls