-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Fix failure for validate API on a terms query #29483
Conversation
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 left some comments.
import java.util.List; | ||
import java.util.Map; | ||
import java.util.Set; | ||
import java.util.*; |
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.
This will fail precommit
.
import org.elasticsearch.search.internal.AliasFilter; | ||
import org.elasticsearch.search.internal.SearchContext; | ||
import org.elasticsearch.search.internal.ShardSearchLocalRequest; | ||
import org.elasticsearch.tasks.Task; | ||
import org.elasticsearch.threadpool.ThreadPool; | ||
import org.elasticsearch.transport.RemoteClusterAware; |
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 see a lot of unnecessary imports here.
ActionListener<org.elasticsearch.index.query.QueryBuilder> rewriteListener = ActionListener.wrap(rewrittenQuery -> { | ||
request.query(rewrittenQuery); | ||
super.doExecute(task, request, listener); | ||
}, ex -> { |
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 added this section (with advice from @imotov) to address a deficiency in the code uncovered by one of our integration tests, org.elasticsearch.validate.SimpleValidateQueryIT.testExplainValidateQueryTwoNodes
, which tests an error case. Because originally I was propagating the listener's onError
method, an XContent exception was being thrown by the server (bad!), rather than wrapped in a response that wraps the error according to our conventions (good! yay, integration tests!).
My "fix" raises a few questions about what the right response looks like, given this context.
Added some integration test fixes, and my own comments about those fixes; I could use some advice on the best way to handle this error in the right way at the point in execution where it's occurring (on the coordinating node, so there are no shards involved yet in the query). |
Pinging @elastic/es-search-aggs |
@jpountz happy to wait |
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.
@pcsanwald I left some comments
@@ -111,7 +113,7 @@ | |||
} | |||
} | |||
rewriteResponse.onResponse(builder); | |||
} catch (IOException ex) { | |||
} catch (IOException|XContentParseException|ParsingException ex) { |
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.
Instead of XContentParseException
I think we should catch its super class IllegalArgumentException
here since I know that we often throw IllegalArgumentException
when validating requests as well
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.
Reminder about this comment in case you missed it before?
} | ||
List<QueryExplanation> explanations = new ArrayList<>(); | ||
// TODO[PCS]: given that we can have multiple indices, what's the best way to include | ||
// these in a query explanation? |
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 assume this TODO still needs to be resolved? I don't have a good solution here other than having something like "__coordinating_node_rewrite__"
in place of the index name
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 think this TODO can be removed now?
false, | ||
explanations, | ||
// TODO[PCS]: is it correct to have 0 for total shards if the request is invalidated before | ||
// it makes it to the shards? I think the answer is probably no? |
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 assume this TODO still needs to be resolved? Again I don't have a great solution here but given that it never made it onto any shard it is true that there were 0 total shards involved in the request, of which 0 succeeded and 0 failed so maybe this is ok?
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.
@pcsanwald I think this is close, I left a couple of comments but they should be quick fixes. I also left a comment on the version checks and how they will need to be dealt with through back-porting to 6.x. I'm happy to walk through this process in more detail with you if you would like.
} | ||
List<QueryExplanation> explanations = new ArrayList<>(); | ||
// TODO[PCS]: given that we can have multiple indices, what's the best way to include | ||
// these in a query explanation? |
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 think this TODO can be removed now?
out.writeOptionalString(index); | ||
} else { | ||
out.writeString(index); | ||
} |
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 think that we should back port this fix to 6.4. These version checks are fine to leave here for now but when you back port you will need to change them to Version.V_6_4_0
in the back ported commit on the 6.x branch an then after that add a new commit to the master branch to change these checks to Version.V_6_4_0
on master too. This process avoids getting CI failures before you've had a chance to back port the commit to 6.x.
@@ -111,7 +113,7 @@ | |||
} | |||
} | |||
rewriteResponse.onResponse(builder); | |||
} catch (IOException ex) { | |||
} catch (IOException|XContentParseException|ParsingException ex) { |
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.
Reminder about this comment in case you missed it before?
@elasticmachine please test this |
@elasticmachine test this please |
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
* WIP commit to try calling rewrite on coordinating node during TransportSearchAction * Use re-written query instead of using the original query * fix incorrect/unused imports and wildcarding * add error handling for cases where an exception is thrown * correct exception handling such that integration tests pass successfully * fix additional case covered by IndicesOptionsIntegrationIT. * add integration test case that verifies queries are now valid * add optional value for index * address review comments: catch superclass of XContentParseException fixes elastic#29483
* master: (68 commits) [DOCS] Removes X-Pack Elasticsearch release notes (#30272) Correct an example in the top-level suggester documentation. (#30224) [DOCS] Removes broken link [DOCS] Adds file realm configuration details (#30221) [DOCS] Adds PKI realm configuration details (#30225) Fix a reference to match_phrase_prefix in the match query docs. (#30282) Fix failure for validate API on a terms query (#29483) [DOCS] Fix 6.4-specific link in changelog (#30314) Remove RepositoriesMetaData variadic constructor (#29569) Test: increase authentication logging for debugging [DOCS] Removes redundant SAML realm settings (#30196) REST Client: Add Request object flavored methods (#29623) [DOCS] Adds changelog to Elasticsearch Reference (#30271) [DOCS] Fixes section error SQL: Teach the CLI to ignore empty commands (#30265) [DOCS] Adds Active Directory realm configuration details (#30223) [DOCS] Removes redundant file realm settings (#30192) [DOCS] Fixes users command name (#30275) Build: Move gradle wrapper jar to a dot dir (#30146) Build: Log a warning if disabling reindex-from-old (#30304)
* Fix failure for validate API on a terms query (#29483) * WIP commit to try calling rewrite on coordinating node during TransportSearchAction * Use re-written query instead of using the original query * fix incorrect/unused imports and wildcarding * add error handling for cases where an exception is thrown * correct exception handling such that integration tests pass successfully * fix additional case covered by IndicesOptionsIntegrationIT. * add integration test case that verifies queries are now valid * add optional value for index * address review comments: catch superclass of XContentParseException fixes #29483 * Backport terms-query-validate-bug changes to 6.x
Fixes #29033, currently WIP as I need to fix a few integration tests. As @colings86 described on the issue, we're missing a step for terms queries, we need to rewrite the query on the coordinating node.
Steps to reproduce (and confirm fix)
Run a local server:
./gradlew server
create index
curl -XPUT 'localhost:9200/twitter' -H 'Content-Type: application/json' -d'{}'
add mapping
curl -XPUT 'localhost:9200/twitter/_mapping/_doc' -H 'Content-Type: application/json' -d'{ "properties": { "user": { "type": "integer" }, "followers": { "type": "integer" } } }'
run a validate request on a terms query:
curl -XPOST 'localhost:9200/twitter/_validate/query?explain=true' -H 'Content-Type: application/json' -d'{ "query": { "terms": { "user": { "index": "twitter", "type": "_doc", "id": "2", "path": "followers" } } } }'