Skip to content

Comments

Add mappings for enrich fields (#96056)#10

Open
MitchLewis930 wants to merge 1 commit intopr_020_beforefrom
pr_020_after
Open

Add mappings for enrich fields (#96056)#10
MitchLewis930 wants to merge 1 commit intopr_020_beforefrom
pr_020_after

Conversation

@MitchLewis930
Copy link

@MitchLewis930 MitchLewis930 commented Jan 29, 2026

PR_020

Summary by CodeRabbit

  • Enhancements

    • Improved mapping validation for enrich fields with stronger conflict detection and safer mapping aggregation across sources.
    • Broadened support for enrich policy types with more robust mapping resolution and clearer error messages.
  • Tests

    • Added coverage for mapping type and format conflict scenarios and introduced a mapping-assertion helper for validation.
  • Documentation

    • Added a changelog entry documenting these updates.

We are developing a new component that performs lookup during query 
time. The idea is to utilize the existing enrich policies and indices 
used during indexing. However, to ensure proper functionality of the new
component, we need the mapping types and doc_values of the enrich
fields.

With this change, populating the mapping for enrich fields is a 
best-effort process to maintain the current behavior. This means that
any mapping conflicts arising between the enrich fields of the source
indices will be ignored. I will follow up to address this validation
issue.
@coderabbitai
Copy link

coderabbitai bot commented Jan 29, 2026

📝 Walkthrough

Walkthrough

Adds a changelog entry and refactors enrich mapping handling in EnrichPolicyRunner to use a MappingTypeAndFormat record and centralized createEnrichMapping logic; expands tests with conflict-mapping cases and adds an assertEnrichMapping helper (duplicated in the file).

Changes

Cohort / File(s) Summary
Changelog Documentation
docs/changelog/96056.yaml
New changelog entry for PR 96056: "Add mappings for enrich fields" (area: Ingest Node, type: enhancement).
Enrich Mapping Refactoring
x-pack/plugin/enrich/src/main/java/org/elasticsearch/xpack/enrich/EnrichPolicyRunner.java
Introduces a private MappingTypeAndFormat record, extractValues helper, RANGE_TYPES constant, and map-driven mapping creation. Adds mappingForMatchField / createEnrichMapping flows, aggregates/validates types and formats across sources, improves error messages, and replaces prior traversal with safer map-based handling.
Test Coverage Expansion
x-pack/plugin/enrich/src/test/java/org/elasticsearch/xpack/enrich/EnrichPolicyRunnerTests.java
Adds testEnrichFieldsConflictMappingTypes and testEnrichMappingConflictFormats; introduces assertEnrichMapping helper and refactors tests to use it. Note: the helper was added twice (duplicate identical method definitions).

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~50 minutes

Poem

🐇 I nibbled mappings, soft and bright,
Found types and formats in the night,
I hop, I check, I catch the clash,
Patch the fields with a gentle bash —
Hooray for indexes, tidy and tight! 🎉

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'Add mappings for enrich fields (#96056)' clearly and concisely describes the main change in the changeset, which centers on adding mapping support for enrich fields across multiple files.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch pr_020_after

Comment @coderabbitai help to get the list of available commands and usage tips.

@MitchLewis930
Copy link
Author

@CodeRabbit full review

@coderabbitai
Copy link

coderabbitai bot commented Jan 29, 2026

✅ Actions performed

Full review triggered.

@MitchLewis930
Copy link
Author

@coderabbitai full review

@coderabbitai
Copy link

coderabbitai bot commented Feb 12, 2026

✅ Actions performed

Full review triggered.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In
`@x-pack/plugin/enrich/src/main/java/org/elasticsearch/xpack/enrich/EnrichPolicyRunner.java`:
- Around line 228-238: The error message in EnrichPolicyRunner's formats
conflict branch uses policy.getMatchField() which is incorrect for non-match
fields; replace that usage with the local fieldName variable so the exception
shows the actual field being validated (update the thrown ElasticsearchException
message invocation in the if (formats.size() > 1) block to pass fieldName
instead of policy.getMatchField(), keeping the rest of the message/arguments the
same).
🧹 Nitpick comments (1)
x-pack/plugin/enrich/src/main/java/org/elasticsearch/xpack/enrich/EnrichPolicyRunner.java (1)

300-302: Unreachable null check (dead code).

This null check is unreachable. If currentField were null after the loop, the method would have already returned at Line 290. This appears to be leftover from refactoring.

♻️ Suggested cleanup
-        if (currentField == null) {
-            return null;
-        }
         final String type = (String) currentField.getOrDefault("type", "object");
📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between def010d and 00afc5b.

📒 Files selected for processing (3)
  • docs/changelog/96056.yaml
  • x-pack/plugin/enrich/src/main/java/org/elasticsearch/xpack/enrich/EnrichPolicyRunner.java
  • x-pack/plugin/enrich/src/test/java/org/elasticsearch/xpack/enrich/EnrichPolicyRunnerTests.java
🔇 Additional comments (10)
x-pack/plugin/enrich/src/main/java/org/elasticsearch/xpack/enrich/EnrichPolicyRunner.java (4)

42-44: LGTM!

The new imports (Maps, Iterables, HashMap) are appropriately added to support the new map-driven mapping construction logic.

Also applies to: 60-60


308-340: LGTM!

The RANGE_TYPES set correctly includes all range types (integer_range, float_range, long_range, double_range, ip_range, date_range), and the mappingForMatchField method properly handles all policy types with appropriate error handling for unknown types.


342-398: LGTM!

The createEnrichMapping method correctly handles the case where the match field is also an enrich field by enabling doc_values (removing the explicit false setting). The map-driven approach is clean and the XContentBuilder usage for serialization is appropriate.


400-418: LGTM!

The integration of the new createEnrichMapping(mappings) method into prepareAndCreateEnrichIndex is clean and maintains the existing control flow.

docs/changelog/96056.yaml (1)

1-5: LGTM!

The changelog entry correctly documents this enhancement with appropriate PR number, summary, area, and type.

x-pack/plugin/enrich/src/test/java/org/elasticsearch/xpack/enrich/EnrichPolicyRunnerTests.java (5)

35-35: LGTM!

The new imports (PlainActionFuture, XContentHelper, ElasticsearchAssertions, Locale) are properly added to support the new test functionality.

Also applies to: 42-42, 58-58, 77-77


2305-2310: LGTM!

The assertEnrichMapping helper method is well-designed, validating that dynamic is set to "false" and comparing the properties against the expected JSON mapping.


2085-2141: LGTM!

This test correctly validates the behavior when enrich fields have conflicting mapping types across source indices. It verifies that:

  1. Fields with conflicting types (name) are excluded from the explicit enrich mapping
  2. Documents still contain the original data regardless of mapping conflicts
  3. Fields with consistent types (user, zipcode) are properly mapped

2143-2185: LGTM!

This test correctly validates the behavior when enrich fields have conflicting date formats across source indices. It confirms that the date field is excluded from the explicit mapping due to format conflict while documents retain their original data.


160-175: LGTM!

The refactoring of mapping assertions to use the declarative assertEnrichMapping helper with JSON strings improves test readability and consistency across all test methods.

✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.

Comment on lines +228 to +238
if (formats.size() > 1) {
if (strictlyRequired) {
throw new ElasticsearchException(
"Multiple distinct formats specified for field '{}' - indices({}) format entries({})",
policy.getMatchField(),
Strings.collectionToCommaDelimitedString(policy.getIndices()),
Strings.collectionToCommaDelimitedString(formats)
);
}
return null;
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Bug: Incorrect field name in error message for format conflicts.

Line 232 uses policy.getMatchField() in the error message, but this method can be called for any field (including enrich fields). This is inconsistent with the type conflict error at Line 217 which correctly uses fieldName.

🐛 Proposed fix
         if (formats.size() > 1) {
             if (strictlyRequired) {
                 throw new ElasticsearchException(
                     "Multiple distinct formats specified for field '{}' - indices({})  format entries({})",
-                    policy.getMatchField(),
+                    fieldName,
                     Strings.collectionToCommaDelimitedString(policy.getIndices()),
                     Strings.collectionToCommaDelimitedString(formats)
                 );
             }
🤖 Prompt for AI Agents
In
`@x-pack/plugin/enrich/src/main/java/org/elasticsearch/xpack/enrich/EnrichPolicyRunner.java`
around lines 228 - 238, The error message in EnrichPolicyRunner's formats
conflict branch uses policy.getMatchField() which is incorrect for non-match
fields; replace that usage with the local fieldName variable so the exception
shows the actual field being validated (update the thrown ElasticsearchException
message invocation in the if (formats.size() > 1) block to pass fieldName
instead of policy.getMatchField(), keeping the rest of the message/arguments the
same).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants