Summary

Extend SearchIndexOptions to include an await boolean type that polls listSearchIndexes to determine the state of a search index operation.

Additionally, drivers should document the asynchronicity of search index operations.

Motivation

As Atlas Vector Search becomes more popular, drivers are likely to see a number of user complaints about the asynchronous nature of operating search indexes. The specifications expect users to poll listSearchIndexes to determine the state of the operation. Given this recommendation, it would be natural to provide users with a convenience await option. For example:

searchIndex.CreateOne(ctx, model, options.CreateSearchIndex().SetAwait(true))

It's notable that polling listSearchIndexes can require a large amount of non-obvious code depending on the language:

var doc bson.Raw
for doc == nil {
	cursor, err := view.List(ctx, options.SearchIndexes().SetName(searchName))
	if err != nil {
		return "", fmt.Errorf("failed to list search indexes: %w", err)
	}

	if !cursor.Next(ctx) {
		break
	}

	name := cursor.Current.Lookup("name").StringValue()
	queryable := cursor.Current.Lookup("queryable").Boolean()
	if name == searchName && queryable {
		doc = cursor.Current
	} else {
		time.Sleep(1 * time.Second)
	}
}

Who is the affected end user?

Anyone creating search indexes.

How likely is it that this problem or use case will occur?

Search index operations returning before the server has created an index is a virtual guaruntee.

If the problem does occur, what are the consequences and how severe are they?

Minor annoyance

Is this issue urgent?

No

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

No

Acceptance Criteria

• Extend SearchIndexOptions to include an await boolean
• Create psuedcode for a suggested await algorithm
• Create unified spec tests to reflect this new option
• Update documentation to require documenting the asynchronicity of search index operations