[jira] [Commented] (SOLR-15031) NPE caused by FunctionQParser returning a null ValueSource

["Pieter (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-15031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294419#comment-17294419 ] 

Pieter commented on SOLR-15031:
-------------------------------

[~dsmiley], I agree with that comment, I also thought the real problem is QParser.parse returning null, but I did not dare to suggest to deal with that. 

Since the introduction of the Java language it supports the concept of null values, which is abused by programmers to give "null" a special meaning. That happened in Lucene too, QParser.parse is allowed to return null when the input does not produce a Query. Java 8 finally brought a solution with the Optional type and I think that would be the ideal solution here too. Changing the return type of QParser.parse however is a breaking change which is though. Maybe we can introduce a new QParser.parse method, mark the current one deprecated and refactor all Lucene&Solr code to use the new?

Alternatively, we can change the contract as you suggest, but that's problematic too because how do we prevent it from breaking stuff? We can refactor all Solr and Lucene code, but people (like me) write their own query parsers and code calling such query parsers. Such code also needs to be reviewed and how do we enforce that? Even if I have a junit test assuming QParser.parse to return null and coding that assumption in a mock QParser, that test will not break after changing the contract. I think the only way to enforce such change and to make sure it is dealt with, is to make a breaking change like changing the return type as suggested above.

> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org