[SOLR-13851] SolrIndexSearcher.getFirstMatch trips assertion if multiple matches

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Assignee: Unassigned
• Reporter: Chris M. Hostetter
• Created: 16/Oct/19 18:14
• Updated: 21/Jan/20 16:56

Description

the documentation for SolrIndexSearcher.getFirstMatch says...

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

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.

Issue Links

• relates to: SOLR-12366 Avoid SlowAtomicReader.getLiveDocs -- it's slow
• relates to: SOLR-13852 TestCloudNestedDocsSort can use the same uniqueKey for both a parent and child doc