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
Do not fail whole request on closed index #6790
Do not fail whole request on closed index #6790
Conversation
@spinscale would this fix also handle the case mentioned in #6410 (comment) when indexing into a non-existent index with |
String type = null; | ||
String id = null; | ||
boolean isClosed = false; | ||
if (request instanceof IndexRequest) { |
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.
dude can we extract and interface that we can implement on all of them that allows use to return index, type, id
?
added some comments |
The bulk API request was marked as completely failed, in case a request with a closed index was referred in any of the requests inside of a bulk one. Closes elastic#6410
@clintongormley added another test when |
* | ||
* Forces this class return index/type/id getters | ||
*/ | ||
public interface SingleDocumentWriteRequest { |
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.
maybe we should call it Indexable
or DocumentRequest
something like this and it should also have a routing or even better the common denominator of update / delete / index ie all the methods they share?
I added some comments |
The bulk API request was marked as completely failed,
in case a request with a closed index was referred in
any of the requests inside of a bulk one.
Implementation Note: Currently the implementation is a bit more verbose in order to prevent an
instanceof
check and another cast - if that is fast enough, we could execute that logic only once at the beginning of the loop (thinking this might be a bit overoptimization here).Closes #6410