Fixes #27482: Advanced Search between operator ignores range bounds for number custom properties#27525
Conversation
|
Hi there 👋 Thanks for your contribution! The OpenMetadata team will review the PR shortly! Once it has been labeled as Let us know if you need any help! |
|
Hi there 👋 Thanks for your contribution! The OpenMetadata team will review the PR shortly! Once it has been labeled as Let us know if you need any help! |
There was a problem hiding this comment.
Pull request overview
Fixes Advanced Search Elasticsearch query generation for extension (custom property) numeric range filters by ensuring between / not_between operators pass both bounds through to the nested range query builder, preventing silently dropped upper bounds and stale-query short-circuiting.
Changes:
- Update
buildEsRuleto pass the full[from, to]array tobuildExtensionQueryforbetween/not_betweenoperators (retain prior scalar behavior for all other operators). - Add Jest coverage validating that both
gteandlteare present forbetween, and thatnot_betweenis properly wrapped in amust_notclause.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| openmetadata-ui/src/main/resources/ui/src/utils/QueryBuilderElasticsearchFormatUtils.js | Fixes extension-field range handling by preserving both bounds for between / not_between. |
| openmetadata-ui/src/main/resources/ui/src/utils/QueryBuilderElasticsearchFormatUtils.test.js | Adds regression tests for extension numeric between and not_between query generation. |
|
hi @harshach sir could you please add a |
|
@mohitjeswani01 this requires playwright tests as well |
Thanks for the review @harshach sir , i will fix the checkstyle and also add playwrite test for the between UI flow. Will push the update shortly. |
Code Review ✅ ApprovedAdvanced search logic now correctly respects range bounds for number-based custom properties, fixing the off-by-one error during filtering. No issues found. OptionsDisplay: compact → Showing less information. Comment with these commands to change:
Was this helpful? React with 👍 / 👎 | Gitar |
|
@harshach The logic is fully locked in, E2E tests are complete, and I've resolved the Copilot review suggestions. However, I am hitting a cross-platform loop with the lint-playwright CI job. The organize-imports-cli tool is sorting the imports slightly differently on my Windows/WSL local environment compared to the GitHub Actions Linux runner. Every time I run the auto-fixers locally and push, the Linux runner reorganizes them and intentionally fails the checkstyle. Since the actual E2E logic is sound, could you please 🙏 run make ui-checkstyle-changed on your end to lock in the Linux import order and bypass the check ? as i am on a 8gb ram machine😅, Let me know if you need me to adjust any actual test logic! |
❌ UI Checkstyle Failed❌ Playwright — ESLint + Prettier + Organise ImportsOne or more Playwright test files have linting or formatting issues. Affected files
Fix locally (fast — only checks files changed in this branch): make ui-checkstyle-changed |
|
🔴 Playwright Results — 3 failure(s), 21 flaky✅ 3664 passed · ❌ 3 failed · 🟡 21 flaky · ⏭️ 89 skipped
Genuine Failures (failed on all attempts)❌
|
|
@harshach Just a heads-up, the Postgresql PR Playwright E2E Tests job had a few failures ( Looking at the traces, these appear to be unrelated CI flakes (async indexing timeouts and a test-data collision where a user email already exists), completely isolated from the QueryBuilderElasticsearchFormatUtils changes in this PR. Could you re-trigger the failed Playwright jobs when you have a moment, or let me know if you'd prefer me to investigate them anyway? |



Description:
Fixes #27482
What changes did you make?
In
QueryBuilderElasticsearchFormatUtils.js, thebuildEsRulefunction passed onlyvalue[0](the lower bound) tobuildExtensionQueryfor all extension field operators. For thebetweenoperator, RAQB stores the two inputs as a flat array[from, to], sovalue[1](the upper bound) was silently dropped before reaching the Elasticsearch range query builder.Fixed by introducing an
isBetweenOpcheck that passes the fullvaluearray forbetween/not_betweenoperators andvalue[0]for all others — no change to existing operator behaviour.Why did you make them?
The filter was ignoring the specified range and returning all entities that had the custom property set regardless of value. For example, filtering between 1 and 5 returned an entity with value 100. A secondary effect was that subsequent Apply clicks did not re-trigger the search API, because the broken query was structurally identical every time and was short-circuited by the
isEqualguard inloadTree.How did you test your changes?
Added a new unit test file
QueryBuilderElasticsearchFormatUtils.test.jswith two tests that driveelasticSearchFormatend-to-end using a minimal RAQB tree stub andAntdConfig:between [5, 20]→ assertsgte: 5andlte: 20both present in the nested range querynot_between [10, 50]→ asserts the range is wrapped in amust_notclause with correct boundsBoth tests pass. ✅
Type of change:
Checklist:
Fixes #27482: Advanced Search between operator ignores range bounds for number custom propertiesSummary by Gitar
AdvanceSearchCustomProperty.spec.tsto improve test reliability and maintainability.This will update automatically on new commits.