-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Scripted Update NPE #48215
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
Pinging @elastic/es-core-infra (:Core/Infra/Scripting) |
The same also happens with version 7.4.0. The script can be reduced to just Edit: |
Potentially related to #30356 |
We need to investigate. It appears to be due to a serialization issue based on the stack trace. |
@rjernst debugged this. We can repro when the document does not exist. When we read in the internal serialization of the result, the boolean value if |
This commit ensures deseriable a GetResult from StreamInput does not leave metaFields and documentFields null. This could cause an NPE in situations where upsert response for a document that did not exist is passed back to a node that forwarded the upsert request. closes elastic#48215
This commit ensures deseriable a GetResult from StreamInput does not leave metaFields and documentFields null. This could cause an NPE in situations where upsert response for a document that did not exist is passed back to a node that forwarded the upsert request. closes #48215
This commit ensures deseriable a GetResult from StreamInput does not leave metaFields and documentFields null. This could cause an NPE in situations where upsert response for a document that did not exist is passed back to a node that forwarded the upsert request. closes #48215
…tic#50112) This commit ensures deseriable a GetResult from StreamInput does not leave metaFields and documentFields null. This could cause an NPE in situations where upsert response for a document that did not exist is passed back to a node that forwarded the upsert request. closes elastic#48215
What's the actual impact of the bug? Are e.g. all indexing/update actions in a bulk request properly handled even if a single one of them fails like this? I'm just trying to understand how critical it is to update to a fixed version (we're seeing these errors as well). |
@slovdahl Yes, bulk requests should continue processing the rest of the documents if some fail. |
Elasticsearch version (
bin/elasticsearch --version
): 7.3.2Plugins installed:
analysis-icu
analysis-kuromoji
analysis-nori
analysis-phonetic
analysis-smartcn
analysis-stconvert
analysis-stempel
ingest-attachment
repository-s3
JVM version (
java -version
):1.8.0_181
OS version (
uname -a
if on a Unix-like system):Linux ip-172-31-2-219 4.4.0-1074-aws #84-Ubuntu SMP Thu Dec 6 08:57:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux and Others
Description of the problem including expected versus actual behavior:
I've encountered what looks like a bug with scripted updates. Running the following request (on a non-data node) results in the error below:
Error:
If the command is run on the data node, everything works as expected.
Steps to reproduce:
Provide logs (if relevant):
See Above
The text was updated successfully, but these errors were encountered: