How do we handle concurrent writes to Azure Search documents?

Question

Use Case and Question

1. making one network call to fetch a document from search into memory,
2. then changing that document in memory, and
3. finally making a second network call to update that document in search.

How can we guarantee that step (3) fails if the document has changed since step (1).

Using an ETag in the request header seems ideal. We found docs on doing that for non-document resources (e.g., index fields), but we found scant documentation on doing that with document resources.

Our Research

• The .NET v11 SearchClient provides .NET methods for the update and the merge operations, but does not explicitly mention concurrency in the XML comments of those methods.

• In the source code for the v11 SearchClient, both the upload and merge operations call into IndexDocumentsInternal. That method has no explicit ETag usage (and it ends up calling into the REST API).

• The REST API headers documentation says of ETags that it supports indexers, indexes, and data sources, but not documents.

• The REST API response documentation includes a 409; however, the docs do not give a lot of information on when this response would be returned. The 409 means that a, version conflict was detected when attempting to index a document. This can happen when you're trying to index the same document more than once concurrently.

This related SO item does not answer our question: Does Azure Search Provides Etags for managing concurrency for Add, Update or Delete Documents?