-
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
Pass runtime_fields from FieldCapabilitiesRequest to FieldCapabilitiesIndexRequest #69853
Pass runtime_fields from FieldCapabilitiesRequest to FieldCapabilitiesIndexRequest #69853
Conversation
Pinging @elastic/es-search (Team:Search) |
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.
The change looks good to me, it would be great to have a way to test this in the "normal" case though (when the remote cluster is on 7.12 or above). I don't know if we have the appropriate test infra though, so I'm currently looking for more information. If this proves to be difficult we should probably merge this for now and open a follow up to add those tests later.
I'm not sure about the test suite for |
@przemekwitek I found yaml tests for "field_caps" under ':qa:multi-cluster-search' and briefly played around with it (see cbuescher@93ca26c). Adding something basic like this with a runtime_mapping that changes a remote fields type should be enough to test the basic propagation I think. |
I verified that your test fails without the fix but passes with the fix. |
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.
Great, thanks again for catching this. LGTM pending CI is green.
number: | ||
type: keyword | ||
script: | ||
source: "emit(doc['number'].value)" |
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.
I am wondering how this is not throwing an error for trying to access doc_values of the field that is being defined. Would it make sense to use a different field name? You can potentially even skip the script.
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.
Though I see that this is also testing shadowing the existing mapped field. Maybe that is not required though as it's besides the scope of this test. We could define a new field as part of runtime_mappings and check that field_caps returns it
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.
Done (skipped the script
part).
I think the script is just not executed during _field_caps
so it's cleaner not to provide it in the first place.
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.
ah right that's it and that is why it was not causing an error :)
This PR makes the
runtime_fields
map passed down to remoteFieldCapabilitiesRequest
s.Additionally:
runtimeFields
member variablefinal
inFieldCapabilitiesIndexRequest
FieldCapabilitiesRequest
Relates to #68904
Marked as
>non-issue
as this is a fix for an unreleased feature.