The search functionality is highly dedicated to updating its internal index as fast as possible. However, while working on highly distributed systems/networks, the search functionality is provided according to “eventual consistency” paradigms. In order to scale accordingly, it guarantees to reach a consistent state at some point in time - but not immediately.
The consistency should recover within some time.
If it is important to know when exactly a twin modification is reflected in the search index, request the search-persisted acknowledgement in the corresponding command. Doing so delays the command response until search index update completes. There is no guarantee that search index update completes before the duration given by the timeout parameter; applications should be ready to handle error statuses such as 408 Request Timeout if only search-persisted is requested, or 424 Dependency Failed if other acknowledgement labels are also requested.
Requesting the search-persisted adds significant latency to command processing and incurs higher costs. Do not request search-persisted unless it is really necessary.
Further reading: https://queue.acm.org/detail.cfm?id=1466448