[
https://issues.apache.org/jira/browse/SOLR-15031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17297179#comment-17297179
]
Pieter commented on SOLR-15031:
-------------------------------
Yes that would help. It will be a lot work of to add the annotations
everywhere, but that's the case for any solution. The big advantage is, it will
be compatible with what we have. New issues, possible bugs will be flagged, but
there will not be a broken build or failing test that needs immediate
attention, so fixing those issues can be planned.
This issue is a nice demonstration of how that would work (I think, haven't
tried it out yet): if QueryValueSource would mark the Query constructor
parameter as @NotNull and QParser.getQuery() would return a @Nullable Query,
then a problem would be detected (while building the code). Issue if fixed by
adding an explicit null check in FunctionQParser as I did in my PR.
Regarding SOLR-8319; since Solr's QParsers (like ExtendedDismaxQParser)
delegate building the Query to QueryBuilder, it makes sense to mark methods in
there to be returning a @Nullable Query as well. Doing so would also deal with
SOLR-8319.
To explore the solution, we could use this issue; cut a branch before my PR is
merged, add annotations in there, observate the warnings being generated, merge
in the PR and see that the warnings are gone.
> NPE caused by FunctionQParser returning a null ValueSource
> ----------------------------------------------------------
>
> Key: SOLR-15031
> URL: https://issues.apache.org/jira/browse/SOLR-15031
> Project: Solr
> Issue Type: Bug
> Reporter: Pieter
> Assignee: Mike Drob
> Priority: Minor
> Fix For: 8.8, master (9.0)
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> When parsing a sub query in a function query,
> {{FunctionQParser#parseValueSource}} does not check if the produced query
> object is null. When it is, it just wraps a null in a {{QueryValueSource}}
> object. This is a cause for NPE's in code consuming that object. Parsed
> queries can be null, for example when the query string only contains
> stopwords, so we need handle that condition.
> h3. Steps to reproduce the issue
> # Start solr with the techproducts example collection: {{solr start -e
> techproducts}}
> # Add a stopword to
> SOLR_DIR/example/techproducts/solr/techproducts/conf/stopwords.txt, for
> example "at"
> # Reload the core
> # Execute a function query:
> {code:java}
> http://localhost:8983/solr/techproducts/select?fieldquery={!field%20f=features%20v=%27%22at%22%27}&q={!func}%20if($fieldquery,1,0){code}
> The following stacktrace is produced:
> {code:java}
> 2020-12-03 13:35:38.868 INFO (qtp2095677157-21) [ x:techproducts]
> o.a.s.c.S.Request [techproducts] webapp=/solr path=/select
> params={q={!func}+if($fieldquery,1,0)&fieldquery={!field+f%3Dfeatures+v%3D'"at"'}}
> status=500 QTime=34
> 2020-12-03 13:35:38.872 ERROR (qtp2095677157-21) [ x:techproducts]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at
> org.apache.lucene.queries.function.valuesource.QueryValueSource.hashCode(QueryValueSource.java:63)
> at
> org.apache.lucene.queries.function.valuesource.IfFunction.hashCode(IfFunction.java:129)
> at
> org.apache.lucene.queries.function.FunctionQuery.hashCode(FunctionQuery.java:176)
> at
> org.apache.solr.search.QueryResultKey.<init>(QueryResultKey.java:53)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1341)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:580)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
