PM-4886 Update default state of talent search#1760
PM-4886 Update default state of talent search#1760himaniraghav3 wants to merge 7 commits intodevfrom
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
| if (selectedCountryCodes.size > 0) { | ||
| const location = String(talent.location || '') | ||
| .trim() | ||
| const upperLocation = location.toUpperCase() | ||
| const lowerLocation = location.toLowerCase() | ||
| const matchesCountryCode = selectedCountryCodes.has(upperLocation) | ||
| || Array.from(selectedCountryCodes) | ||
| .some(code => upperLocation.endsWith(` ${code}`)) | ||
| const matchesCountryName = selectedCountryNames.some(name => ( | ||
| lowerLocation === name || lowerLocation.endsWith(` ${name}`) | ||
| )) | ||
|
|
||
| if (!matchesCountryCode && !matchesCountryName) { | ||
| return false | ||
| } | ||
| } |
There was a problem hiding this comment.
🟡 Client-side country filter can drop valid results already filtered by server
Country codes are now sent server-side via payload.countries (TalentSearchPage.tsx:217-219), but the filteredResults memo also applies a client-side heuristic filter that matches against talent.location using endsWith. This dual filtering is problematic: the server filters by exact country code, but the client checks whether the location string ends with the country code or name. If the API returns a member whose location field doesn't follow the pattern "City, CODE" or "City, Country Name" (e.g., it's empty, just a city name, or uses a different separator like "/"), the client-side filter will drop valid results that the server correctly included.
Example of the problematic client-side filter
If the server returns a member with location: "New York" for a US-country-code filter, the client check at lines 115-120 will fail:
selectedCountryCodes.has("NEW YORK")→ false"NEW YORK".endsWith(" US")→ false"new york".endsWith(" united states")→ false
→ The valid result is dropped.
Prompt for agents
The client-side country filter in filteredResults (lines 110-125) is now redundant with the server-side country filter added at lines 217-219 of runMemberSearch. The server receives exact country codes and handles filtering reliably, while the client filter uses fragile location-string matching that can produce false negatives.
The simplest fix is to remove the client-side country filter block entirely (lines 110-125 in filteredResults), since the server already handles country filtering via the countries parameter in the payload. The onlyActive and onlyOpenToWork client-side filters can remain as they are also server-side filtered and use exact boolean matching (no heuristics), so they are safe defensive checks.
Alternatively, if you want to keep the client-side country filter as a defensive measure, you could make it more lenient by using .includes() instead of .endsWith(), or by using the countryNameByCode map to resolve the location to a country code first and then matching against selectedCountryCodes.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Related JIRA Ticket:
https://topcoder.atlassian.net/browse/PM-4886
What's in this PR?
By default alphabetical order of users is shown in talent search UI
On searching for members through JD, we show skill filter search sorted by matching index