-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
word_delimiter_graph combined with length filter produces array_index_out_of_bounds_exception during query building #46272
Comments
Pinging @elastic/es-search |
Thanks for reporting this issue @xabbu42, this should not result in an error. In the master branches this currently results in an assertion error being thrown:
|
@martijnvg I am also facing the same issue. I have tested both on v7.3.2 and on master branch: got Please note that Logs (looks like a lucene bug):
|
Just tried on 7.4.0 and narrowing this down a bit more: The NPE reproduces with the above script, but only if the
Also changing the order of search terms doesn't trigger the NPE:
The code path the NPE is triggered expects a Term[] or length > 0 which we even assert when assertions are enabled. This assumption seemst to be violated in this particular case. |
This came up again in #54434, so adding a summary of how this manifests in 7.6. Stack trace on 7.6.1:
Basically this error can happen whenever a filter produces a tokenstream with a graph structure (here the word-delimiter-grapg), e.g. by splitting sth. like "3d" on numerics while keeping the original aswell (here "3", "d" and "3d"), and a subsequent filter removes some of these tokens (here the length filter). The corresponding token stream is turned into an Automaton inside Short reproduction on 7.6.1:
The token streams produced by word delimiter filter and the length filter look like this
I will need to discuss this some more and understand how the underlying automaton gets constructed to see if we have a chance of detecting this early or even mitigate it. |
Some intermediate results: The way we build the Automaton doesn't always deal well with deleted tokens. Without the length filter and deleting the tokens the Automaton we build in
When the two single-letter token get deleted we currently create four states with the following transitions:
Later after removing dead states the Automaton is empty, leading to the exception later on in our code. Dealing with deletions in token streams for graphs in a general way seems challanging. There are some open issues like https://issues.apache.org/jira/browse/LUCENE-8717 that might be able to adress this problem in a way in the future. We might be able to detect when the built Automaton is empty although the token stream isn't, throwing a different exception then but I'm not sure how helpful that would be over the current behaviour. |
We're continuing to see this error in our production environment. Any word on when it will be addressed? |
Very interested in this issue as well as we get many of it in production. |
Are they related apache/lucene#11864? |
Pinging @elastic/es-search (Team:Search) |
This is still an issue with elasticsearch 8.6.2. I had to add a _refresh to the script to reproduce it though. |
Pinging @elastic/es-search-relevance (Team:Search Relevance) |
Elasticsearch version (
bin/elasticsearch --version
):Version: 7.3.0, Build: default/tar/de777fa/2019-07-24T18:30:11.767338Z, JVM: 1.8.0_212
I also tested the below reproduction on 7.3.1
Plugins installed: [analysis-icu]
JVM version (
java -version
):openjdk version "1.8.0_212"
OpenJDK Runtime Environment (IcedTea 3.12.0) (build 1.8.0_212-b4 suse-2.2-x86_64)
OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)
OS version (
uname -a
if on a Unix-like system):Linux duktig 5.1.16-1-default #1 SMP Wed Jul 3 12:37:47 UTC 2019 (2af8a22) x86_64 x86_64 x86_64 GNU/Linux
Description of the problem including expected versus actual behavior:
Building query for the below index settings and query fails with array_index_out_of_bounds_exception. It should build a query as it did with elasticsearch 6.8 (I did not test the exact steps below on 6.8 but the original error this script is based on did not happen on 6.8).
Steps to reproduce:
The text was updated successfully, but these errors were encountered: