Note that search queries are out of scope.
Essentially we will allow to register a "completion handler" which will define how to behave once indexing works have been sent:
wait until full completion (synchronous)
do not wait (asynchronous)
custom, for example wait for 1 second, and if it's not finished by then, fall back to some behavior that only makes sense for longer operations (notify with an UI message or an email when the operation ends, for example).
Note that we should be careful: when some backend enlists in the transaction (thus requiring to wait for the execution to end before we can proceed), we should always wait for completion, either before or after the user-configured completion handler. Maybe after would be better, since it would still allow custom blocking behaviors.
We might want to allow users to define a default behavior, applied by default to every session.
Also, we should think about allowing to configure the "level" of completion which is expected: in Elasticsearch for example, we might want to wait for works to be fully sent to the cluster, or to wait a bit more for the result of these works to be visible (refresh), potentially triggering the refresh manually. This would require deeper interaction with the backend, probably passing the "refresh_after_write" setting from the mapper instead of setting in the index configuration as we currently do.