ROX-34014: Fix label search filter formatting for key=value pairs#19902
ROX-34014: Fix label search filter formatting for key=value pairs#19902
Conversation
|
This change is part of the following stack: Change managed by git-spice. |
|
Skipping CI for Draft Pull Request. |
1881466 to
7099dff
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #19902 +/- ##
=======================================
Coverage 49.58% 49.58%
=======================================
Files 2766 2766
Lines 208535 208535
=======================================
Hits 103409 103409
Misses 97448 97448
Partials 7678 7678
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- In
applyRegexSearchModifiers, the label-specific branch callsisQuotedString(val)twice and recomputesrawValuebased on that; consider storing the boolean and sliced value once to simplify the logic and avoid repeated work. - The
isLabelSearchTerm/labelSearchOptionslogic hardcodes the set of label search terms by display name; if new label fields are added insearchOptions, you might want to derive this set from metadata instead of duplicating the list to avoid future drift.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In `applyRegexSearchModifiers`, the label-specific branch calls `isQuotedString(val)` twice and recomputes `rawValue` based on that; consider storing the boolean and sliced value once to simplify the logic and avoid repeated work.
- The `isLabelSearchTerm`/`labelSearchOptions` logic hardcodes the set of label search terms by display name; if new label fields are added in `searchOptions`, you might want to derive this set from metadata instead of duplicating the list to avoid future drift.
## Individual Comments
### Comment 1
<location path="ui/apps/platform/src/utils/searchUtils.ts" line_range="435-436" />
<code_context>
+ Search terms that use the key=value label format and need special handling
+ in both regex and exact-match search modes.
+*/
+const labelSearchOptions: Set<string> = new Set(
+ ['Cluster Label', 'Deployment Label', 'Image Label', 'Namespace Label', 'Node Label'].map(
+ (label) => label.toLowerCase()
+ )
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider deriving label search terms from existing search configuration to avoid string drift.
These label names are hard-coded but also defined in the search configuration used for `regexSearchOptions` and the UI. If a label is renamed or a new label type is added there but not here, `isLabelSearchTerm` will become outdated and label-specific formatting will quietly stop working. To avoid this drift, consider building this set from the same configuration (e.g., via an `isLabel` flag or `category` enum) instead of a separate hard-coded list.
Suggested implementation:
```typescript
/*
Search terms that use the key=value label format and need special handling
in both regex and exact-match search modes.
Derive these from the shared search configuration to avoid drift with the UI.
*/
const labelSearchOptions: Set<string> = new Set(
searchOptions
.filter(({ isLabel }) => isLabel)
.map(({ searchTerm }) => searchTerm.toLowerCase())
);
```
To make this compile and behave as intended, you will also need to:
1. Ensure the search configuration object used here (referred to as `searchOptions`) is accessible in this module (either already imported or exported from wherever `regexSearchOptions` is derived).
2. Add an `isLabel: boolean` (or similar metadata such as `category: 'label'`) property to each label-related entry in that search configuration (e.g., Cluster Label, Deployment Label, Image Label, Namespace Label, Node Label, and any new label types you add in the future).
3. If `searchOptions` currently has a different name in this file, adjust the reference in the `labelSearchOptions` definition accordingly.
</issue_to_address>
### Comment 2
<location path="ui/apps/platform/src/utils/searchUtils.ts" line_range="484" />
<code_context>
+ * - Regex: app=reporting -> r/app=r/reporting, report -> r/report=r/report
+ * - Exact: app=reporting -> "app"="reporting"
*/
export function applyRegexSearchModifiers(searchFilter: SearchFilter): SearchFilter {
const regexSearchFilter = cloneDeep(searchFilter);
</code_context>
<issue_to_address>
**issue (complexity):** Consider extracting the label-specific and generic regex formatting into small helper functions so `applyRegexSearchModifiers` has a simpler, flatter map callback.
You can flatten `applyRegexSearchModifiers` by pushing the label-specific branching into a helper and making the quoted/non‑quoted decision once per value.
For example:
```ts
function formatRegexValue(val: string): string {
return isQuotedString(val) ? val : `r/${val}`;
}
function formatLabelRegexValue(val: string): string {
const quoted = isQuotedString(val);
const rawValue = quoted ? val.slice(1, -1) : val;
const formatter = quoted ? wrapInQuotes : (v: string) => `r/${v}`;
return formatLabelValue(rawValue, formatter);
}
```
Then `applyRegexSearchModifiers` becomes:
```ts
export function applyRegexSearchModifiers(searchFilter: SearchFilter): SearchFilter {
const regexSearchFilter = cloneDeep(searchFilter);
Object.entries(regexSearchFilter).forEach(([key, value]) => {
if (regexSearchOptions.some((option) => option.toLowerCase() === key.toLowerCase())) {
const isLabel = isLabelSearchTerm(key);
regexSearchFilter[key] = searchValueAsArray(value).map((val) =>
isLabel ? formatLabelRegexValue(val) : formatRegexValue(val)
);
}
});
return regexSearchFilter;
}
```
This keeps all existing behavior (including the label key=value semantics and quoted handling) but removes the nested `if` plus duplicated inline `isQuotedString`/`formatter` logic from the `.map` callback, making the control flow easier to follow.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| * - Regex: app=reporting -> r/app=r/reporting, report -> r/report=r/report | ||
| * - Exact: app=reporting -> "app"="reporting" | ||
| */ | ||
| export function applyRegexSearchModifiers(searchFilter: SearchFilter): SearchFilter { |
There was a problem hiding this comment.
issue (complexity): Consider extracting the label-specific and generic regex formatting into small helper functions so applyRegexSearchModifiers has a simpler, flatter map callback.
You can flatten applyRegexSearchModifiers by pushing the label-specific branching into a helper and making the quoted/non‑quoted decision once per value.
For example:
function formatRegexValue(val: string): string {
return isQuotedString(val) ? val : `r/${val}`;
}
function formatLabelRegexValue(val: string): string {
const quoted = isQuotedString(val);
const rawValue = quoted ? val.slice(1, -1) : val;
const formatter = quoted ? wrapInQuotes : (v: string) => `r/${v}`;
return formatLabelValue(rawValue, formatter);
}Then applyRegexSearchModifiers becomes:
export function applyRegexSearchModifiers(searchFilter: SearchFilter): SearchFilter {
const regexSearchFilter = cloneDeep(searchFilter);
Object.entries(regexSearchFilter).forEach(([key, value]) => {
if (regexSearchOptions.some((option) => option.toLowerCase() === key.toLowerCase())) {
const isLabel = isLabelSearchTerm(key);
regexSearchFilter[key] = searchValueAsArray(value).map((val) =>
isLabel ? formatLabelRegexValue(val) : formatRegexValue(val)
);
}
});
return regexSearchFilter;
}This keeps all existing behavior (including the label key=value semantics and quoted handling) but removes the nested if plus duplicated inline isQuotedString/formatter logic from the .map callback, making the control flow easier to follow.
🚀 Build Images ReadyImages are ready for commit 7099dff. To use with deploy scripts: export MAIN_IMAGE_TAG=4.11.x-600-g7099dffb5a |
Description
Fixes label search filters (Deployment Label, Image Label, Node Label, Namespace Label, Cluster Label) to properly format key=value pairs for the search API.
Problem: Label search filters were not correctly handling the key=value format required by the backend. Labels need special quoting where each side of the equals sign is processed separately.
Solution: Added
formatLabelValueutility that splits on the first=and applies formatting to each part:app=reporting→"app"="reporting"app=reporting→r/app=r/reportingreport→r/report=r/report)Why this approach: The backend treats labels as key=value pairs. Previous implementation wrapped the entire string in quotes or regex prefix, breaking the semantic meaning.
User-facing documentation
Testing and quality
Automated testing
How I validated my change
formatLabelValue,isLabelSearchTerm, and integration withapplyRegexSearchModifiers