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