Skip to content

Answer queries on an index with no documents - #106

Open
danielgreen wants to merge 2 commits into
feature23:mainfrom
danielgreen:fix/empty-index-search
Open

danielgreen wants to merge 2 commits into
feature23:mainfrom
danielgreen:fix/empty-index-search

Conversation

@danielgreen

Copy link
Copy Markdown

Fixes #105

An index that has had no documents written has no Lucene directory yet. Opening a reader on it threw DirectoryNotFoundException, so search, get-by-key, suggest and autocomplete answered 500. Azure answers an empty result (and 404 for a missing key).

The reader factory now checks DirectoryReader.IndexExists and, if there is no Lucene index, returns an empty reader. The empty reader is not cached, and indexing already refreshes the cached reader after each commit, so the first write is visible to the next read. The check is on the read side, so indexes created before this change also work.

Tests:

  • Unit tests in EmptyIndexTests use the real reader factory over an on-disk directory that does not exist (an in-memory directory would pass without the fix). They cover search, count, get-by-key, suggest, autocomplete, a folder that exists but is empty, and a search that finds a document uploaded after an empty read.
  • An integration test covers the same over HTTP.
  • ErrorResponseIntegrationTests.UnexpectedFailure_ReturnsEnvelopeWithoutInternalDetail relied on the old 500. It now uses an unparseable full Lucene query (search=(&queryType=full), which still answers 500. That is a separate gap, since Azure answers 400.
  • DebugClient has a new check that searches an empty index.

I can file the malformed full-syntax query 500 (Azure answers 400) as a separate issue if you want.

Searching, counting or fetching a document from an index that had no
documents written yet failed with a 500 (DirectoryNotFoundException),
because the Lucene directory does not exist until the first write.
Azure answers with an empty result, a count of 0 and a 404 for the key.

When the directory holds no Lucene index, the reader factory now returns
an empty reader. It is not cached, so the first write is seen by the next
read. This also covers indexes created before this change.

The unexpected-failure integration test relied on that 500, so it now
uses a full Lucene query that does not parse.
@paulirwin

Copy link
Copy Markdown
Member

Thanks for all the PRs, I'll be looking at getting these merged very soon!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Searching an index that has no documents returns 500

2 participants