Fixes 33542: index description positions so Contains filters can match

[harshach]

Describe your changes:

Fixes #33542. Salvaged from the closed PR #33248 (tracking: #33528).

A Contains filter on description silently returns nothing on five search indexes — no error, no
warning, just zero hits. A Contains filter compiles to a phrase query, and a phrase query needs
token positions in the inverted index. Elasticsearch's default index_options for a text field
is positions; these five mappings explicitly downgrade it below that:

Index	was	now
en/glossary_term_search_index	docs	positions
ru/glossary_term_search_index	docs	positions
jp/metric_search_index	docs	positions
zh/api_endpoint_search_index	freqs	positions
zh/metric_search_index	docs	positions

docs stores neither frequencies nor positions; freqs stores frequencies but no positions. Either
way the phrase query has nothing to match against.

Three of the five compound the contradiction by also declaring "term_vector": "with_positions_offsets" — asking for positions in the term vector while index_options strips them
from the index. The mapping blocks are authored by copying an existing entity's file, which is how a
setting like this reaches some entities and not others.

⚠ Reindex required. IndexMappingVersionTracker hashes each mapping file, so the affected
indexes are flagged for reindex automatically — but an existing deployment needs that reindex to run
before descriptions become searchable by phrase.

Type of change:

• Bug fix

High-level design:

Five one-line mapping changes. The interesting choice is the guard: rather than a test that asserts
"these five files are correct", dataAssetDescriptionsSupportPhraseQueries is a property test
over every index carrying the dataAsset parent alias, in all four languages, that fails naming any
offender. A sixth entity added later by copying one of these files is caught by the same test instead
of needing this issue filed again.

Tests:

Use cases covered

• Filtering Glossary Terms by a phrase in their description returns matches (en, ru).
• Same for Metrics (jp, zh) and API Endpoints (zh).
• Indexes that already had positions are unaffected.

Unit tests

IndexAnalyzerMappingTest#dataAssetDescriptionsSupportPhraseQueries — new, and fails on main
naming exactly the five indexes this PR fixes:

Description Contains requires indexed positions:
  [en/glossary_term_search_index, ru/glossary_term_search_index, jp/metric_search_index,
   zh/api_endpoint_search_index, zh/metric_search_index]

After the change the class is 6/6 green, the 5 pre-existing analyzer-chain tests included.

Backend integration tests

Not applicable — no API change. Behaviour is in the shipped index mappings.

Ingestion integration tests

Not applicable.

Playwright (UI) tests

Not applicable — no UI change.

Manual testing performed

1. Added the test first and ran it against unmodified main — it named the five indexes above.
2. mvn -pl openmetadata-spec install -DskipTests then
   mvn -pl openmetadata-service test -Dtest=IndexAnalyzerMappingTest — 6 tests, BUILD SUCCESS.
   (The service test reads mappings from the spec jar, so the spec module has to be reinstalled or
   the run silently uses the old mappings.)
3. Verified the edit landed on the top-level mappings.properties.description in each file and
   not on a nested one — the diff is exactly 5 files, 1 line each.
4. mvn spotless:apply -pl openmetadata-service — clean.

UI screen recording / screenshots:

Not applicable.

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• My PR is linked to a GitHub issue via Fixes #33542.
• I have commented on my code, particularly in hard-to-understand areas.
• For JSON Schema changes: these are index mappings, not entity schemas — no migration script; the reindex requirement is noted above.
• For UI changes: not applicable.
• I have added tests and listed them above.
• I have added a test that covers the exact scenario we are fixing.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge, with the mapping changes and regression test consistently enforcing phrase-query support.

Summary

Updates five localized Elasticsearch mappings so description fields retain token positions required by phrase-based Contains filters.

• Changes affected description fields from docs or freqs to positions.
• Adds a property-style test covering all data-asset mappings across the supported mapping languages.
• Relies on mapping hash changes to trigger the required reindex.

_{Reviews (5) · Last reviewed commit: "Merge branch 'main' into harshach/fix-de..."}

[github-actions]

✅ PR checks passed

The linked issue has a description and all required Shipping project fields set. Thanks!

[gitar-bot]

Code Review ✅ Approved

🟡 Medium risk

Fixes phrase query support on description fields by correcting index_options from docs/freqs to positions across five search index mappings in multiple languages. A property test verifies that all dataAsset indexes support phrase queries on descriptions, catching similar issues on future entities. No issues found.

Review coverage

Rules No rules evaluated

Functional validation Not enabled · Set up

Auto-approval Not enabled · Set up

Options

Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ingestion'

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