Hi @HenningAndersen,
So _delete_by_query basically searches for the documents to delete and then deletes them one by one. And a version conflict occurs if one or more of the documents gets update in between the time when the search was completed and the delete operation was started.
But as I said, I had received a successful created/updated response for all the documents that have to deleted, before sending the _delete_by_query request. And I am pretty sure that that none of the documents are getting updated during the time duration when _delete_by_query is running.
So I am guessing that a successful creation/updation does not imply that that the data is successfully persisted across the primary and replica shards (and is available immediately for search) but instead is written to some kind of translog and then persisted on required nodes once a refresh is done.
Assuming my above assumption to be correct, _delete_by_query will throw a version conflict when a refresh occurs just after the search operation (of _delete_by_query) completes and delete operation starts.
Please correct me if I am wrong.