Version conflict coming without passing version es 5.6

[Dilip_Kumar]

Hi
I am using elasticsearch with two nodes with both as master (elasticsearch 5.6). when i am sending update query with php client then getting error ;
message '{"error":{"root_cause":[{"type":"version_conflict_engine_exception","reason":"[mytype][123456_789]: version conflict, current version [25] is different than the one provided .

my request to es engine i am not giving any version with update api:
ELASTIC_HOST=array("192.168.1.yyy:9200","192.168.1.xxx:9200");
$hosts = $ELASTIC_HOST;
$res = Elasticsearch\ClientBuilder::create()->setHosts($hosts)->build();

$params = array();
$params['index'] = $index;
$params['type'] = $type;
$document = array("doc"=>array("val"=>"1"));
$json_esData = json_encode($document);
$params['id'] = 123456_789;
$params['body'] = $json_esData;
$es_response = $res->update($params);

Please guide me how can i avoid this error

[polyfractal (Zachary Tong)]

Update requests internally use versions to make sure the update is semantically correct. What happened is that the Update API fetched the document, noted the version, applied the changes and tried to reindex it. After fetching but before reindexing the change, some other process updated the document and so the update failed.

You just need to retry the update, or specify retry_on_conflict to do it automatically.

[Dilip_Kumar]

Thank you polyfractal, i need to add ['retry_on_conflict'] = 5 , is it ok
but what will happen according to you one request will go for update internally with previous version (suppose going update for 62) but version 63 is available.. what will do retry_on_conflict..

[polyfractal (Zachary Tong)]

The internal version is basically just a counter, so if an update tries to act on an old version (e.g. update for version 62, but current version is 63), the update will be rejected. And if you have retry_on_conflict enabled it will just fetch the new version number and try again.

That's why updates with retry_on_conflict must be idempotent...they have to be applicable in any order, because you can't guarantee what order they will be applied in. Incrementing a counter is idempotent... it doesn't matter if it happens before or after another update.

But changing a name may not be, because it may depend on the old value. In that case you should probably handle the conflict in your application.

[Dilip_Kumar]

@polyfractal

But changing a name may not be, because it may depend on the old value. In that case you should probably handle the conflict in your application.

Thank you for valuable suggestion, can we use this for bulk uppdate

[polyfractal (Zachary Tong)]

Yep, version can be supplied in bulk updates too.