fix: node group filter uses exact match and drops empty filter entries

[claude]

Requested by Pawan Mehta · Slack thread

Description

Fixes two bugs in the Resource Browser → Nodes page "Node Groups" filter:

1. Substring match instead of exact match — filtering by a node group name (e.g. presto-gateway) also matched nodes from a distinct, similarly-named node group (e.g. presto-gateway-2), because the match used .includes() instead of exact equality.
2. Stray empty filter entry silently disabled the filter — a blank/empty entry could end up in the applied filter list alongside a real node group value (e.g. because nodes without a node group contributed a blank option to the filter list, and nothing stripped falsy values before persisting to the URL). Since the matching logic checks .some() across the comma-separated filter values, and every string "includes" the empty string, one blank entry caused the whole filter to match every node — with no obvious indication in the UI.

Related Issue(s)

Fixes devtron-labs/devtron#6997

Before / After

Before

• Selecting node group presto-gateway also showed nodes belonging to presto-gateway-2.
• Applying a node group filter could silently have no effect at all (all nodes still shown) when a blank filter entry snuck in, with no visible indication why.

After

• Selecting node group presto-gateway shows only nodes whose node group is exactly presto-gateway.
• Nodes without a node group never contribute a blank option to the filter list, and any falsy-value filter entry is stripped before it's persisted to the URL / applied filter state, so the filter can no longer be neutralized this way.

Root cause

• src/components/ResourceBrowser/ResourceList/utils.tsx — isItemASearchMatchForNodeListing compared the node group value with String(item[objectKey] ?? '').includes(trimmedText) instead of exact equality, and iterated comma-separated filter values with .some(), so a single empty value always matched.
• src/components/ResourceBrowser/ResourceList/utils.tsx — getNodeSearchKeysOptionsList added a node-group option for every row without checking whether curr.data.nodeGroup was actually set, so nodes without a node group (e.g. control-plane nodes) contributed a blank/invisible option to the filter dropdown.
• src/components/ResourceBrowser/ResourceList/NodeListSearchFilter.tsx — handleSearchFilterChange wrote whatever options were selected straight into the query string without filtering out falsy values.

What changed

• utils.tsx: isItemASearchMatchForNodeListing now uses strict equality (===) for the node group comparison instead of .includes().
• utils.tsx: getNodeSearchKeysOptionsList skips building a node-group option when curr.data.nodeGroup is falsy.
• NodeListSearchFilter.tsx: handleSearchFilterChange filters out falsy-value entries before persisting filters to the query string (applies to all three filter categories: node group, label, k8s version).
• NodeListSearchFilter.tsx: the FilterChips filterConfig now consistently filters out falsy values for all three categories (previously only node group was defensively filtered for display).

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• npx tsc --noEmit — clean, no errors.

• npx eslint on both changed files with --max-warnings 0 — clean.

• Manually traced the matching logic (isItemASearchMatchForNodeListing) against sample node group values (presto-gateway vs presto-gateway-2, and a blank entry alongside a real one) to confirm the exact-match fix and the empty-entry stripping resolve both reported symptoms.

• Typecheck (tsc --noEmit)

• Lint (eslint --max-warnings 0 on changed files)

Checklist:

• The title of the PR states what changed and the related issues number (used for the release note).
• Does this PR require documentation updates?
• I've updated documentation as required by this PR.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas

The base branch was changed.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud