feat: add support for range field types in Discover

[mmustafasenoglu]

Description

Add support for OpenSearch range field types (integer_range, float_range, long_range, double_range, date_range, ip_range) in Discover. These types were missing since OpenSearch was forked from Elasticsearch 7.12, causing range fields to display as unknown.

Approach

Range fields are interval/object values ({gte, lte}), not scalar values. Instead of mapping them to scalar OSD types, range fields are modeled with distinct OSD field types:

OpenSearch field type	OSD field type
integer_range, float_range, long_range, double_range	NUMBER_RANGE
date_range	DATE_RANGE
ip_range	IP_RANGE

These types default to sortable: false, filterable: false, preventing invalid sort/filter/aggregation operations.

Changes

• types.ts: Added NUMBER_RANGE, DATE_RANGE, IP_RANGE to OSD_FIELD_TYPES enum + range OpenSearch types
• osd_field_types_factory.ts: Added 3 new OsdFieldType entries with range-specific esTypes mappings
• osd_field_types.test.ts: Updated cast and type name tests for new range types
• field_editor.test.tsx.snap: Updated snapshot to include new range field types

Related issue

Closes #11053

Note

Previous PR #12393 was closed due to test snapshot failures and missing DCO sign-off. This is a single squashed commit with all fixes applied and DCO signed.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 604d209)

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Inconsistency with PR description The PR description states range fields default to filterable: false to prevent invalid filter/aggregation operations, but all three new OsdFieldType entries (NUMBER_RANGE, DATE_RANGE, IP_RANGE) are created with filterable: true. This contradicts the stated design intent and may allow invalid filter operations on range fields. Verify the intended default and align either the code or the description. new OsdFieldType({ name: OSD_FIELD_TYPES.NUMBER_RANGE, filterable: true, esTypes: [ OPENSEARCH_FIELD_TYPES.INTEGER_RANGE, OPENSEARCH_FIELD_TYPES.FLOAT_RANGE, OPENSEARCH_FIELD_TYPES.LONG_RANGE, OPENSEARCH_FIELD_TYPES.DOUBLE_RANGE, ], }), new OsdFieldType({ name: OSD_FIELD_TYPES.DATE_RANGE, filterable: true, esTypes: [OPENSEARCH_FIELD_TYPES.DATE_RANGE], }), new OsdFieldType({ name: OSD_FIELD_TYPES.IP_RANGE, filterable: true, esTypes: [OPENSEARCH_FIELD_TYPES.IP_RANGE], }),

[github-actions]

PR Code Suggestions ✨

Latest suggestions up to 76e942e

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Mark range field types as filterable Range field types should likely be marked as filterable: true (similar to HISTOGRAM and other numeric/date/ip types) so users can filter on them in Discover. Without this flag, the UI may disable filtering interactions on range fields, defeating part of the purpose of exposing them. src/plugins/data/common/osd_field_types/osd_field_types_factory.ts [122-138] new OsdFieldType({ name: OSD_FIELD_TYPES.NUMBER_RANGE, + filterable: true, esTypes: [ OPENSEARCH_FIELD_TYPES.INTEGER_RANGE, OPENSEARCH_FIELD_TYPES.FLOAT_RANGE, OPENSEARCH_FIELD_TYPES.LONG_RANGE, OPENSEARCH_FIELD_TYPES.DOUBLE_RANGE, ], }), new OsdFieldType({ name: OSD_FIELD_TYPES.DATE_RANGE, + filterable: true, esTypes: [OPENSEARCH_FIELD_TYPES.DATE_RANGE], }), new OsdFieldType({ name: OSD_FIELD_TYPES.IP_RANGE, + filterable: true, esTypes: [OPENSEARCH_FIELD_TYPES.IP_RANGE], }), Suggestion importance[1-10]: 6 __ Why: Reasonable suggestion since HISTOGRAM and other similar types are marked filterable: true, and range types support filtering in OpenSearch. However, without confirmation on UI behavior for range types, the impact is moderate.	Low

---

Previous suggestions

Suggestions up to commit 9080f88

Category	Suggestion	Impact
General	Mark new range types as filterable The existing HISTOGRAM type is registered with filterable: true, but the new range types omit this flag and default to non-filterable. Since OpenSearch range fields do support term/range queries, consider setting filterable: true to enable filtering in Discover, which is consistent with how the underlying primitive types (number, date, ip) are treated. src/plugins/data/common/osd_field_types/osd_field_types_factory.ts [122-138] new OsdFieldType({ name: OSD_FIELD_TYPES.NUMBER_RANGE, + filterable: true, esTypes: [ OPENSEARCH_FIELD_TYPES.INTEGER_RANGE, OPENSEARCH_FIELD_TYPES.FLOAT_RANGE, OPENSEARCH_FIELD_TYPES.LONG_RANGE, OPENSEARCH_FIELD_TYPES.DOUBLE_RANGE, ], }), new OsdFieldType({ name: OSD_FIELD_TYPES.DATE_RANGE, + filterable: true, esTypes: [OPENSEARCH_FIELD_TYPES.DATE_RANGE], }), new OsdFieldType({ name: OSD_FIELD_TYPES.IP_RANGE, + filterable: true, esTypes: [OPENSEARCH_FIELD_TYPES.IP_RANGE], }), Suggestion importance[1-10]: 6 __ Why: Reasonable suggestion since range fields do support filtering in OpenSearch, and the underlying primitive types are filterable. However, without knowing the intended UX or downstream behavior, the impact is moderate and could be intentional.	Low

Suggestions up to commit 29be468

Category	Suggestion	Impact
General	Mark range field types as filterable Range fields in OpenSearch support term-based queries (matching documents whose range contains a value), so they should be marked filterable: true to allow filtering in Discover. Without this, users won't be able to add filters on range-typed fields even though the backend supports it. src/plugins/data/common/osd_field_types/osd_field_types_factory.ts [122-138] new OsdFieldType({ name: OSD_FIELD_TYPES.NUMBER_RANGE, + filterable: true, esTypes: [ OPENSEARCH_FIELD_TYPES.INTEGER_RANGE, OPENSEARCH_FIELD_TYPES.FLOAT_RANGE, OPENSEARCH_FIELD_TYPES.LONG_RANGE, OPENSEARCH_FIELD_TYPES.DOUBLE_RANGE, ], }), new OsdFieldType({ name: OSD_FIELD_TYPES.DATE_RANGE, + filterable: true, esTypes: [OPENSEARCH_FIELD_TYPES.DATE_RANGE], }), new OsdFieldType({ name: OSD_FIELD_TYPES.IP_RANGE, + filterable: true, esTypes: [OPENSEARCH_FIELD_TYPES.IP_RANGE], }), Suggestion importance[1-10]: 6 __ Why: Range field types do support term queries in OpenSearch, so marking them filterable: true (consistent with HISTOGRAM above) is a reasonable enhancement. However, the suggestion is speculative regarding UI behavior and impact, and correctness depends on the broader system's ability to construct filters on range types.	Low

Suggestions up to commit 7eba96f

Category	Suggestion	Impact
General	Mark new range types as filterable The new range field types are not marked as filterable, which is inconsistent with similar aggregatable types like NUMBER, DATE, and IP in this factory. Since range fields are indexed and support term/range queries in OpenSearch, they should be filterable to allow Discover users to apply filters on them, which is the primary intent of this feature. src/plugins/data/common/osd_field_types/osd_field_types_factory.ts [122-138] new OsdFieldType({ name: OSD_FIELD_TYPES.NUMBER_RANGE, + filterable: true, esTypes: [ OPENSEARCH_FIELD_TYPES.INTEGER_RANGE, OPENSEARCH_FIELD_TYPES.FLOAT_RANGE, OPENSEARCH_FIELD_TYPES.LONG_RANGE, OPENSEARCH_FIELD_TYPES.DOUBLE_RANGE, ], }), new OsdFieldType({ name: OSD_FIELD_TYPES.DATE_RANGE, + filterable: true, esTypes: [OPENSEARCH_FIELD_TYPES.DATE_RANGE], }), new OsdFieldType({ name: OSD_FIELD_TYPES.IP_RANGE, + filterable: true, esTypes: [OPENSEARCH_FIELD_TYPES.IP_RANGE], }), Suggestion importance[1-10]: 6 __ Why: Range fields are indexed and queryable in OpenSearch, so marking them as filterable: true aligns with NUMBER, DATE, and IP types and enables filtering in Discover. This is a reasonable enhancement but requires verification that downstream filter UIs support range types.	Low

[github-actions]

Persistent review updated to latest commit 29be468

[github-actions]

Persistent review updated to latest commit 9080f88

[github-actions]

🔗 Workflow run · commit 9080f883e88e3d705988a608466221f4b42632aa

❌ 3 Jest Test Failure(s)

📄 junit-jest-group4-Linux/TEST-Jest Tests.xml

❌ Query Actions - Comprehensive Test Suite abortAllActiveQueries should abort all active queries and clear controllers (0.032s)

Jest Tests.src/plugins/explore/public/application/utils/state_management/actions

Error: expect(received).toMatchSnapshot()

Snapshot name: `FieldEditor should show deprecated lang warning 1`

- Snapshot  -  0
+ Received  + 12

@@ -158,10 +158,22 @@
              Object {
                "text": "histogram",
  … (22 more lines)

📄 junit-jest-group4-Windows/TEST-Jest Tests.xml

❌ Query Actions - Comprehensive Test Suite abortAllActiveQueries should abort all active queries and clear controllers (0.053s)

Jest Tests.src\plugins\explore\public\application\utils\state_management\actions

Error: expect(received).toMatchSnapshot()

Snapshot name: `FieldEditor should show deprecated lang warning 1`

- Snapshot  -  0
+ Received  + 12

@@ -158,10 +158,22 @@
              Object {
                "text": "histogram",
  … (22 more lines)

📄 junit-jest-group5-Windows/TEST-Jest Tests.xml

❌ InstantSelectorVisitor parsing and visiting correctness should handle mixed labels, time ranges, and functions correctly (0.015s)

Jest Tests.src\plugins\data\public\antlr\promql

Error: thrown: "Exceeded timeout of 5000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
    at it (D:\a\OpenSearch-Dashboards\OpenSearch-Dashboards\src\plugins\data_source_management\public\components\direct_query_data_sources_components\acceleration_management\acceleration_table.test.tsx:100:3)
    at _dispatchDescribe (D:\a\OpenSearch-Dashboards\OpenSearch-Dashboards\node_modules\jest-circus\build\jestAdapterInit.js:608:26)
    at describe (D:\a\OpenSearch-Dashboards\OpenSearch-Dashboards\node_modules\jest-circus\build\jestAdapterInit.js:576:44)
    at Object.describe (D:\a\OpenSearch-Dashboards\OpenSearch-Dashboards\src\plugins\data_source_management\public\components\direct_query_data_sources_components\acceleration_management\acceleration_table.test.tsx:95:1)
    at ModuleExecutor.exec (D:\a\OpenSearch-Dashboards\OpenSearch-Dashboards\node_modules\jest-runtime\build\index.js:2078:26)
    at CjsLoader.loadModule (D:\a\OpenSearch-Dashboards\OpenSearch-Dashboards\node_modules\jest-runtime\build\index.js:323:36)
    at CjsLoader.requireModule (D:\a\OpenSearch-Dashboards\OpenSearch-Dashboards\node_modules\jest-runtime\build\index.js:289:12)
    at Runtime.requireModule (D:\a\OpenSearch-Dashboards\OpenSearch-Dashboards\node_modules\jest-runtime\build\index.js:3657:27)
  … (3 more lines)

---

3 failure(s) across 3 suite(s). Full XML reports are in the junit-jest-* artifacts.

[github-actions]

Persistent review updated to latest commit 76e942e

[github-actions]

Persistent review updated to latest commit 604d209

[Hailong-am]

does it support natively in discover? do we need other changes for building DSL queries

[mmustafasenoglu]

Hi @Hailong-am, yes — the range field types are displayed natively in Discover after this change.

Range fields (, , , , , ) are mapped to distinct OSD field types (, , ) with the appropriate filterable/aggregatable flags and range bar visualization.

For DSL queries: OpenSearch's query DSL already supports range fields natively (e.g. {"range": {"field": {"gte": 10, "lte": 20}}}). The gap was on the OSD side — these field types were not recognized, so they showed as unknown in Discover. This PR fills that gap. No additional backend/DSL changes are needed.

[Hailong-am]

Hi @Hailong-am, yes — the range field types are displayed natively in Discover after this change.

Range fields (, , , , , ) are mapped to distinct OSD field types (, , ) with the appropriate filterable/aggregatable flags and range bar visualization.

For DSL queries: OpenSearch's query DSL already supports range fields natively (e.g. {"range": {"field": {"gte": 10, "lte": 20}}}). The gap was on the OSD side — these field types were not recognized, so they showed as unknown in Discover. This PR fills that gap. No additional backend/DSL changes are needed.

sounds good. Can you fix DCO as well?