We are unit testing our Java application using the (awesome!) Atlas Search Local Deployments.

However, we are seeing a longer delay than we'd like between the time we add data to a collection and the time it is searchable in the Atlas Search Lucene index.

It is almost always uniformly 1 second.

Here's a unit test that demonstrates the issue:
https://github.com/luketn/atlas-search-unit-test-latency-issue/blob/main/src/test/java/com/mycodefu/MainTest.java#L95

This should take a few milliseconds to run, but it will take almost exactly a minute.

Each iteration of the loop in the test will take almost exactly 1s.

The first iteration will usually be shorter, because we start somewhere in the middle of the 1s refresh period:

Time taken for search query to find document: 556ms

Example output of iterations:
> Time taken for search query to find document: 1009ms
> Time taken for search query to find document: 989ms
> Time taken for search query to find document: 1018ms

Output at the end:
> Time taken for test to run: 60s

It may be sensible in production use cases for the eventual consistency of Atlas Search to be 1s. However during unit testing this presents a real problem.

I'm not sure what the best solution would be, but perhaps the indexes could be made available in a more realtime fashion (particularly for unit testing).

A couple of ideas for a solution:
- allow a write concern by connection or insert/update which triggers immediate refresh of the Atlas Search indexes so that you could selectively
- instead of using a periodic refresh on a 1s basis, update the queryable indexes in real time as changes are written (not sure if there are tradeoffs)
- support a command which can be used to trigger an update on Atlas Search indexes