Await for FTS index to update

When writing tests that involve the FTS engine, I’m stuck with stone age technique of thread cpu-busy loop to wait the FTS engine to index my documents.

I have tried the following :

int retry = 0;

while (cluster.searchQuery("myIndex", SearchQuery.docId(myDocument.getId())).rows().isEmpty()) {
    if (retry > 60) fail("Document indexation in FTS timeout");
    Thread.sleep(1000);
    retry++;
}

But it gave me inconsistent results. I guess it waits for the index to acknowledge the document but the document is not yet ready to be searched. Sometimes, on a small sized machine overwhelmed by test suites, a dozen of seconds can separate acknowledgement from readiness.

Is there a common wait to deal with this ?

Edit : in my tests I’m using FTS inside a N1QL query, I don’t know if that matters.

[mikereiche]

Use this url curl -u <username>:<password> http://<ip>:8094/api/nsstats

check for bucket_name:index_name:num_mutations_to_index = 0. In the unit tests, we use okhttp client for things like this.

{
  "batch_bytes_added": 13198,
  "batch_bytes_removed": 13198,
  "curr_batches_blocked_by_herder": 0,
  "my_bucket:myTestIndex:avg_grpc_internal_queries_latency": 0,
.
.
.
  "my_bucket:myTestIndex:num_files_on_disk": 4,
  "my_bucket:myTestIndex:num_mutations_to_index": 0,

[mikereiche]

“This requires the latest token from the last insert ?” I don’t believe the order that documents are inserted can be inferred from the order they were inserted. And even if they could, if the inserts are done with the reactive API, there’s no way to know the order the inserts actually occurred. One could look at the CAS, but then again, that’s another assumption.

As I mentioned earlier, there is the “num_mutations_to_index”. That will be zero when all mutations have been indexed. Is that not sufficient?