Fix dynamic mapping with dotted field names for vector types#143421
Merged
mayya-sharipova merged 1 commit intoelastic:9.3from Mar 3, 2026
Merged
Fix dynamic mapping with dotted field names for vector types#143421mayya-sharipova merged 1 commit intoelastic:9.3from
mayya-sharipova merged 1 commit intoelastic:9.3from
Conversation
PR elastic#130540 introduced a bug where indexing a document with a dotted field name (e.g. "my_vectors.vector1") matched by a dynamic template for dense_vector or rank_vectors without explicit dims would fail with: IllegalStateException: Missing intermediate object. The bug only manifests when dims are not set in the mapping or template, triggering the code path that dynamically determines dimensions from the first indexed document. The root cause is that when DenseVectorFieldMapper and RankVectorsFieldMapper dynamically determine dims, they rebuild the mapper using the document parser's content path. For dynamically mapped fields with dotted names, the content path includes the field name itself rather than just the parent object path, producing a duplicated full path in the rebuilt mapper. This was fixed on main/9.4 by PR elastic#142754, which refactored dynamic mapper tracking to use Mapper.Builder objects. This commit provides a targeted fix for 9.3.x by deriving the correct parent path from the existing mapper's fullPath instead of relying on the content path. The same fix is applied to both DenseVectorFieldMapper and RankVectorsFieldMapper, which shared the same bug.
Collaborator
|
Pinging @elastic/es-search-relevance (Team:Search Relevance) |
benwtrent
approved these changes
Mar 2, 2026
Member
benwtrent
left a comment
There was a problem hiding this comment.
I think this is fine :).
@romseygeek you have been playing around with mappers a bunch recently, any strong opinions?
Contributor
|
LGTM. Glad that I accidentally fixed it on main! |
mayya-sharipova
added a commit
to mayya-sharipova/elasticsearch
that referenced
this pull request
Mar 4, 2026
PR elastic#143421 introduced test features mapper.dense_vector.dynamic_template_dotted_field_fix and mapper.rank_vectors.dynamic_template_dotted_field_fix on the 9.3 branch. The underlying bug was already fixed on 9.4 by During rolling upgrades test from 9.3 to 9.4 the feature barrier in NodeJoinExecutor rejects the 9.4 node: Node is missing required features [mapper.dense_vector.dynamic_template_dotted_field_fix, mapper.rank_vectors.dynamic_template_dotted_field_fix] This PR declares the same NodeFeatures in 9.4 and add the corresponding YAML regression tests.
mayya-sharipova
added a commit
that referenced
this pull request
Mar 4, 2026
PR #143421 introduced test features mapper.dense_vector.dynamic_template_dotted_field_fix and mapper.rank_vectors.dynamic_template_dotted_field_fix on the 9.3 branch. The underlying bug was already fixed on 9.4 by During rolling upgrades test from 9.3 to 9.4 the feature barrier in NodeJoinExecutor rejects the 9.4 node: Node is missing required features [mapper.dense_vector.dynamic_template_dotted_field_fix, mapper.rank_vectors.dynamic_template_dotted_field_fix] This PR declares the same NodeFeatures in 9.4 and add the corresponding YAML regression tests. * Remove YAML tests for vector dotted field fix
burqen
pushed a commit
to burqen/elasticsearch
that referenced
this pull request
Mar 5, 2026
PR elastic#143421 introduced test features mapper.dense_vector.dynamic_template_dotted_field_fix and mapper.rank_vectors.dynamic_template_dotted_field_fix on the 9.3 branch. The underlying bug was already fixed on 9.4 by During rolling upgrades test from 9.3 to 9.4 the feature barrier in NodeJoinExecutor rejects the 9.4 node: Node is missing required features [mapper.dense_vector.dynamic_template_dotted_field_fix, mapper.rank_vectors.dynamic_template_dotted_field_fix] This PR declares the same NodeFeatures in 9.4 and add the corresponding YAML regression tests. * Remove YAML tests for vector dotted field fix
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR #130540 introduced a bug where indexing a
document with a dotted field name (e.g. "my_vectors.vector1") matched by a dynamic template for dense_vector or rank_vectors without explicit dims would fail with:
IllegalStateException: Missing intermediate object.
The bug only manifests when dims are not set in the mapping or template, triggering the code path that dynamically determines dimensions from the first indexed document.
The root cause is that when DenseVectorFieldMapper and RankVectorsFieldMapper dynamically determine dims, they rebuild the mapper using the document parser's content path. For dynamically mapped fields with dotted names, the content path includes the field name itself rather than just the parent object path, producing a duplicated full path in the rebuilt mapper.
This was fixed on main/9.4 by PR #142754, which refactored dynamic mapper tracking to use Mapper.Builder objects. This commit provides a targeted fix for 9.3.x by deriving the correct parent path from the existing mapper's fullPath instead of relying on the content path.
The same fix is applied to both DenseVectorFieldMapper and RankVectorsFieldMapper, which shared the same bug.