fix(inbox): forward reviewer search query to the server

[pauldambra]

Problem

Assigning a reviewer in the Inbox only surfaced people whose first name fell in roughly the first half of the alphabet (up to ~"M"), and typing a name that came later returned "No users found" — even for someone who is definitely in the org. This blocked assigning a large set of teammates as reviewers.

Changes

The Add-reviewer popover called useInboxAvailableSuggestedReviewers with no query and then filtered the result client-side. The backend available_reviewers endpoint returns only the first 100 users sorted by first name, so anyone after the cutoff was never in the fetched set and couldn't be found by searching.

This forwards the popover's deferredQuery into the hook so the search hits the server, which filters before applying its 100-row cap — making any teammate findable by typing their name. The hook already plumbs the query through its query key and into the API call; this just passes it in.

Note: this is the frontend half. The backend [:100] cap (in PostHog/posthog products/signals/backend/views.py) still truncates the default unsearched list and should be revisited separately.

How did you test this?

Not run — node_modules isn't installed in this environment, so the workspace typecheck can't resolve. The change only passes a string into an options field already typed as query?: string, and the hook already handles query forwarding and cache-keying.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

---

Created with PostHog Code from a Slack thread

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 4cb81e8.}

[greptile-apps]

Comments Outside Diff (1)

1. packages/ui/src/features/inbox/components/SuggestedReviewersSection.tsx, line 109-122 (link)

   The client-side filter is now redundant. The hook already trims and forwards deferredQuery to the API call, so availableReviewers.results already contains only server-matched entries. Re-filtering that set with the same deferredQuery is a no-op in the normal case, but in an edge case it can silently drop results: if the server matched a user via a field the client doesn't check (e.g. a display name alias), the client filter will exclude them even though the server intentionally included them.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: packages/ui/src/features/inbox/components/SuggestedReviewersSection.tsx
   Line: 109-122
   
   Comment:
   The client-side filter is now redundant. The hook already trims and forwards `deferredQuery` to the API call, so `availableReviewers.results` already contains only server-matched entries. Re-filtering that set with the same `deferredQuery` is a no-op in the normal case, but in an edge case it can silently drop results: if the server matched a user via a field the client doesn't check (e.g. a display name alias), the client filter will exclude them even though the server intentionally included them.
   
   
   
   How can I resolve this? If you propose a fix, please make it concise.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/ui/src/features/inbox/components/SuggestedReviewersSection.tsx:109-122
The client-side filter is now redundant. The hook already trims and forwards `deferredQuery` to the API call, so `availableReviewers.results` already contains only server-matched entries. Re-filtering that set with the same `deferredQuery` is a no-op in the normal case, but in an edge case it can silently drop results: if the server matched a user via a field the client doesn't check (e.g. a display name alias), the client filter will exclude them even though the server intentionally included them.

```suggestion
  const addableOptions = useMemo(() => {
    return buildSuggestedReviewerFilterOptions(
      availableReviewers?.results ?? [],
      currentUser,
    );
  }, [availableReviewers?.results, currentUser]);
```

_{Reviews (1): Last reviewed commit: "fix(inbox): forward reviewer search quer..." | Re-trigger Greptile}

[pauldambra]

Note

🤖 Automated comment by QA Swarm — not written by a human

Multi-perspective review: qa-team (correctness/tests), paul-reviewer (pragmatism), xp-reviewer (UX/DX), security-audit

Verdict: ✅ APPROVE

One-line change that forwards deferredQuery into useInboxAvailableSuggestedReviewers, activating server-side reviewer search. All supporting plumbing (API client query param via URLSearchParams.set, per-query React Query key, cache-bypass for non-empty queries, retained client-side filter as a safety net) was already in place — this completes the wiring correctly. No correctness, UX, or security concerns.

Key findings

No findings.

Convergence

None.

Reviewer summaries

Reviewer	Assessment
🔍 qa-team	Correct value (deferredQuery) forwarded into already-tested hook; query key namespaces per search, client filter retained safely. No test needed for a prop forward.
👤 paul	Minimal, obviously-correct completion of existing wiring. Ships.
📐 xp	Deferred value keeps typing responsive; empty-query path keeps cached base list so no spinner flash. Good UX.
🛡 security-audit	Query encoded via URLSearchParams on a team-scoped authed GET; no injection/IDOR/SSRF surface. Clean.

---

Automated by QA Swarm — not a human review

[github-actions]

Single-line fix passing an already-computed deferred query value to the hook — purely additive, no risk of data loss or breakage.