-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't modify source map when parsing composite runtime field #89114
Don't modify source map when parsing composite runtime field #89114
Conversation
Pinging @elastic/es-search (Team:Search) |
Hi @romseygeek, I've created a changelog YAML for you. |
OK this doesn't quite work because we need to distinguish between parsing at mapping time or at search time within the composite field as well. I'm digging further... |
…-bug' into runtime/composite-multishard-bug
Actually it looks as though it was a bug in serialization that wasn't caught before because the fields map was being emptied at parse time and so the unnecessary code to output it never actually got triggered. This is ready for review now @javanna |
server/src/main/java/org/elasticsearch/index/mapper/CompositeRuntimeField.java
Show resolved
Hide resolved
@elasticmachine update branch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…#89114) When calling RuntimeField.parseRuntimeFields() for fields defined in the search request, we need to wrap the Map containing field definitions in another Map that supports value removal, so that we don't inadvertently remove the definitions from the root request. CompositeRuntimeField was not doing this extra wrapping, which meant that requests that went to multiple shards and that therefore parsed the definitions multiple times would throw an error complaining that the fields parameter was missing, because the root request had been modified.
When calling
RuntimeField.parseRuntimeFields()
for fields defined in thesearch request, we need to wrap the Map containing field definitions in another
Map that supports value removal, so that we don't inadvertently remove the
definitions from the root request. CompositeRuntimeField was not doing this
extra wrapping, which meant that requests that went to multiple shards and
that therefore parsed the definitions multiple times would throw an error
complaining that the fields parameter was missing, because the root request
had been modified.