Fix generation of dynamic mapping for object with specific subfield #204104
Conversation
This file contains 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
botelastic
bot
added
the
Team:Fleet
|
Pinging @elastic/fleet (Team:Fleet) |
jsoriano
added
release_note:fix
backport:prev-major
jsoriano
force-pushed
the
dynamic-mapping-non-empty-object
branch
from
a481fb2 to
3aa3782
Compare
4 tasks
| - name: labels.count | ||
| type: long | ||
| `; | ||
| const objectFieldWithPropertyReversedMapping = { |
There was a problem hiding this comment.
should there be a test with group type?
There was a problem hiding this comment.
The group type cannot have object_type. Only internally in fleet after the deduplication.
|
Starting backport for target branches: 8.16, 8.17, 8.x |
💚 Build Succeeded
Metrics [docs]
History
cc @jsoriano |
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Dec 16, 2024
…lastic#204104) Fix generation of dynamic mapping for objects that have more specific subfields in separate definitions. This can be reproduced for example with: ``` - name: labels type: object object_type: keyword object_type_mapping_type: '*' - name: labels.count type: long ``` Fleet expands and deduplicates field definitions before generating the mappings, so the definitions above are converted to something like the following: ``` - name: labels type: group object_type: keyword object_type_mapping_type: '*' fields: - name: count type: long ``` Usually fields of type `group` don't have an `object_type`, so this was being ignored, the dynamic mapping was not being generated. This issue was not reproduced if the object field name includes a wildcard, like in `labels.*`, because then the expansion and deduplication resolves to something like this: ``` - name: labels type: group fields: - name: '*' type: object object_type: keyword object_type_mapping_type: '*' - name: count type: long ``` (cherry picked from commit e3877e0)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Dec 16, 2024
…lastic#204104) Fix generation of dynamic mapping for objects that have more specific subfields in separate definitions. This can be reproduced for example with: ``` - name: labels type: object object_type: keyword object_type_mapping_type: '*' - name: labels.count type: long ``` Fleet expands and deduplicates field definitions before generating the mappings, so the definitions above are converted to something like the following: ``` - name: labels type: group object_type: keyword object_type_mapping_type: '*' fields: - name: count type: long ``` Usually fields of type `group` don't have an `object_type`, so this was being ignored, the dynamic mapping was not being generated. This issue was not reproduced if the object field name includes a wildcard, like in `labels.*`, because then the expansion and deduplication resolves to something like this: ``` - name: labels type: group fields: - name: '*' type: object object_type: keyword object_type_mapping_type: '*' - name: count type: long ``` (cherry picked from commit e3877e0)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Dec 16, 2024
…lastic#204104) Fix generation of dynamic mapping for objects that have more specific subfields in separate definitions. This can be reproduced for example with: ``` - name: labels type: object object_type: keyword object_type_mapping_type: '*' - name: labels.count type: long ``` Fleet expands and deduplicates field definitions before generating the mappings, so the definitions above are converted to something like the following: ``` - name: labels type: group object_type: keyword object_type_mapping_type: '*' fields: - name: count type: long ``` Usually fields of type `group` don't have an `object_type`, so this was being ignored, the dynamic mapping was not being generated. This issue was not reproduced if the object field name includes a wildcard, like in `labels.*`, because then the expansion and deduplication resolves to something like this: ``` - name: labels type: group fields: - name: '*' type: object object_type: keyword object_type_mapping_type: '*' - name: count type: long ``` (cherry picked from commit e3877e0)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
kibanamachine
added
the
backport missing
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
1 similar comment
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
JoseLuisGJ
pushed a commit
to JoseLuisGJ/kibana
that referenced
this pull request
Dec 19, 2024
…lastic#204104) Fix generation of dynamic mapping for objects that have more specific subfields in separate definitions. This can be reproduced for example with: ``` - name: labels type: object object_type: keyword object_type_mapping_type: '*' - name: labels.count type: long ``` Fleet expands and deduplicates field definitions before generating the mappings, so the definitions above are converted to something like the following: ``` - name: labels type: group object_type: keyword object_type_mapping_type: '*' fields: - name: count type: long ``` Usually fields of type `group` don't have an `object_type`, so this was being ignored, the dynamic mapping was not being generated. This issue was not reproduced if the object field name includes a wildcard, like in `labels.*`, because then the expansion and deduplication resolves to something like this: ``` - name: labels type: group fields: - name: '*' type: object object_type: keyword object_type_mapping_type: '*' - name: count type: long ```
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
1 similar comment
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Fix generation of dynamic mapping for objects that have more specific subfields in separate definitions.
This can be reproduced for example with:
Fleet expands and deduplicates field definitions before generating the mappings, so the definitions above are converted to something like the following:
Usually fields of type
groupdon't have anobject_type, so this was being ignored, the dynamic mapping was not being generated.This issue was not reproduced if the object field name includes a wildcard, like in
labels.*, because then the expansion and deduplication resolves to something like this:Checklist
release_note:*label is applied per the guidelinesIdentify risks
Probability: low, we have only found one package (see Add initial support to validate the mappings in system tests elastic-package#2214 (comment)).
Severity: low, in the package where we have found this issue, applying an equivalent workaround (Workaround issue with missing dynamic mapping in tines package integrations#12082) doesn't cause any issue, at least with the testing coverage we have. There are no reasons to think that these additional mappings can cause problems, as they correspond with the intention of the package developer.