You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Chris M. Hostetter (Jira)" <ji...@apache.org> on 2019/10/16 18:16:00 UTC
[jira] [Commented] (SOLR-13851) SolrIndexSearcher.getFirstMatch
trips assertion if multiple matches
[ https://issues.apache.org/jira/browse/SOLR-13851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953070#comment-16953070 ]
Chris M. Hostetter commented on SOLR-13851:
-------------------------------------------
Background: I recently noticed jenkins test failures from TestCloudNestedDocsSort that stemmed from this assertion error...
{noformat}
[junit4] 2> <pre> Server Error</pre></p><h3>Caused by:</h3><pre>java.lang.AssertionError
[junit4] 2> at org.apache.solr.search.SolrIndexSearcher.lookupId(SolrIndexSearcher.java:710)
[junit4] 2> at org.apache.solr.search.SolrIndexSearcher.getFirstMatch(SolrIndexSearcher.java:676)
[junit4] 2> at org.apache.solr.handler.component.QueryComponent.doProcessSearchByIds(QueryComponent.java:1266)
[junit4] 2> at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:351)
[junit4] 2> at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:305)
[junit4] 2> at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
[junit4] 2> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
{noformat}
At the core of the problem is that TestCloudNestedDocsSort does some things it shouldn't in terms of fhild doc uniqueKeys (which i'll track in a linked jira) ... but while using git bisect to identify when/where the failure was introduced, it identified GIT:1e63b32731bedf108aaeeb5d0a04d671f5663102 (SOLR-12366) as the first bad commit, and that's when i realized that prior to SOLR-12366 this (bad test) worked fine because {{getFirstMatch}} just did what it says: returned the first match (w/o complaining if there were multiples)
> SolrIndexSearcher.getFirstMatch trips assertion if multiple matches
> -------------------------------------------------------------------
>
> Key: SOLR-13851
> URL: https://issues.apache.org/jira/browse/SOLR-13851
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
>
> the documentation for {{SolrIndexSearcher.getFirstMatch}} says...
> {quote}
> Returns the first document number containing the term <code>t</code> Returns -1 if no document was found. This method is primarily intended for clients that want to fetch documents using a unique identifier."
> @return the first document number containing the term
> {quote}
> But SOLR-12366 refactored {{SolrIndexSearcher.getFirstMatch}} to eliminate it's previous implementation and replace it with a call to (a refactored version of) {{SolrIndexSearcher.lookupId}} -- but the code in {{lookupId}} was always designed *explicitly* for dealing with a uniqueKey field, and has an assertion that once it finds a match _there will be no other matches in the index_
> This means that even though {{getFirstMatch}} is _intended_ for fields that are unique between documents, i it's used on a field that is not unique, it can trip an assertion.
> At a minimum we need to either "fix" {{getFirstMatch}} to behave as documented, or fix it's documetation.
> Given that the current behavior has now been in place since Solr 7.4, and given that all existing uses in "core" solr code are for looking up docs by uniqueKey, it's probably best to simply fix the documentation, but we should also consider replacing hte assertion with an IllegalStateException, or SolrException -- anything not dependent on having assertions enabled -- to prevent silent bugs.
--
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