-
Notifications
You must be signed in to change notification settings - Fork 1.2k
SearchTemplateDescriptor Explain method #5040
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
Comments
Thanks for raising @wyeager! As you correctly conclude, the search template request adds the elasticsearch-net/src/Nest/Requests.NoNamespace.cs Lines 3031 to 3036 in 13aed8a
This is because the REST API spec for search template defines it as a query string param (and the REST API specs do not have details about the request body): elasticsearch-net/src/ApiGenerator/RestSpecification/Core/search_template.json Lines 79 to 82 in 13aed8a
To fix this, the API generator for search template needs to be updated to
Is this something that you'd like to tackle? |
Resolved in #6098. Will be released in |
NEST/Elasticsearch.Net version:
7.9.0
Elasticsearch version:
7.9.2
Description of the problem including expected versus actual behavior:
SearchTemplateDescriptor Explain method places ?explain=true in URL when instead the endpoint seems to need "explain": true key value pair in request body
Steps to reproduce:
Each element of searchResponse.Hits will have null for the value of its Explanation field.
Expected behavior
I would expect the Explanation field of each element of searchResponse.Hits to have a value when I call Explain() on the SearchTemplateDescriptor.
Additional Info:
I can send this raw request to:
http://localhost:9200/myIndex/_search/template
and _explanation has a value.
However, setting ?explain=true in the URL and omitting "explain": true from the request body, like this:
http://localhost:9200/myIndex/_search/template?explain=true
does not return an explanation.
I'm pretty sure the cause of the bug is that the SearchTemplateDescriptor Explain method is structuring the request the second way when it should be structuring it the first way.
The text was updated successfully, but these errors were encountered: