# After upgrade to 9.3.4 problem with version\_conflict\_engine\_exception

**URL:** <https://discuss.elastic.co/t/after-upgrade-to-9-3-4-problem-with-version-conflict-engine-exception/386162>\
**Category:** Elasticsearch\
**Created:** [May 5, 2026, 6:02am UTC](https://discuss.elastic.co/t/after-upgrade-to-9-3-4-problem-with-version-conflict-engine-exception/386162 "2026-05-05T06:02:11Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mario\_22](https://avatars.discourse-cdn.com/v4/letter/m/4491bb/32.png) [@Mario\_22](https://discuss.elastic.co/u/Mario_22)\
**Post date:** [May 5, 2026, 6:02am UTC](https://discuss.elastic.co/t/after-upgrade-to-9-3-4-problem-with-version-conflict-engine-exception/386162/1 "2026-05-05T06:02:11Z")

</div>

After upgrading the Elastic Stack, Fleet Server, and Elastic Agents to 9.3.4, and after re-enabling / upgrading integrations, we started seeing a very large number of errors in logs-elastic\_agent-\*.

The errors look like this:

`message: failed to index document`  
`error.type: version_conflict_engine_exception`  
`http.response.status_code: 409`  
`hint: check the "Known issues" section of Elasticsearch Exporter docs`

Example target data streams / backing indices:

`.ds-metrics-elasticsearch.stack_monitoring.shard-default-...`  
`.ds-metrics-sql-default-...`

Initially, we mostly observed this for Elasticsearch Stack Monitoring, especially the dataset:

`metrics-elasticsearch.stack_monitoring.shard`

Later, similar errors also appeared for SQL metrics.

> Sample log  
> {  
> "message": "failed to index document",  
> "error.type": "version\_conflict\_engine\_exception",  
> "http.response.status\_code": 409,  
> "hint": "check the "Known issues" section of Elasticsearch Exporter docs",  
> "index": ".ds-metrics-elasticsearch.stack\_monitoring.shard-default-2026.04.01-000023",  
> "otelcol.component.id": "elasticsearch/\_agent-component/default",  
> "otelcol.component.kind": "exporter",  
> "otelcol.signal": "logs",  
> "resource.service.name": "/opt/Elastic/Agent/data/elastic-agent-9.3.4-.../components/elastic-otel-collector",  
> "resource.service.version": "9.3.4"  
> }

For SQL metrics, the error is similar.

The main operational impact is a very large amount of error noise in logs-elastic\_agent-\*.

We do not see an Elasticsearch cluster failure at the same time. The cluster is not red and primary shards are available. Metrics appear to be partially or mostly visible in Kibana, but we are not sure whether all metric samples are preserved or whether some samples are rejected as duplicates.

The Elasticsearch Exporter documentation says that version\_conflict\_engine\_exception can be a normal sign of duplicate detection in TSDB metrics data streams, but it also states that in some cases data may be classified as duplicate even when it was not, which implies possible data loss.

What we have checked

We have verified that:

- The Elasticsearch cluster is running and is not red.
- Primary shards are available.
- Elastic Agent is Healthy.
- The integrations are enabled.
- The issue started after the 9.3.4 upgrade / after re-enabling integrations.
- Most errors are related to TSDB metrics, especially stack\_monitoring.shard and SQL metrics.
- The error is emitted by elastic-otel-collector / elasticsearchexporter, not by a custom application log pipeline.

Has anyone encountered this problem? Do you know of a solution?

---

<div class="post-metadata">

**Author:** ![adminunix](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@adminunix](https://discuss.elastic.co/u/adminunix)\
**Post date:** [May 5, 2026, 12:37pm UTC](https://discuss.elastic.co/t/after-upgrade-to-9-3-4-problem-with-version-conflict-engine-exception/386162/2 "2026-05-05T12:37:20Z")

</div>

Hello,

I have the same problem after updating elastic agent.  
This error causes that index statistics are not ingested and Stack Monitoring does not display data for the indices.

I have also read the "Known issues" section of Elasticsearch Exporter but there is no clear solution.

Someone else with this issue?

Regards

---

<div class="post-metadata">

**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\
**Post date:** [May 5, 2026, 12:41pm UTC](https://discuss.elastic.co/t/after-upgrade-to-9-3-4-problem-with-version-conflict-engine-exception/386162/3 "2026-05-05T12:41:33Z")

</div>

Those 409 errors were ignored by normal beats, but they aren't being ignored with the new otel collector.

The fix will be available on future versions, probably 9.3.5 or 9.4.0.

You can check the PR [here](https://github.com/elastic/elastic-agent/pull/13623).

---

<div class="post-metadata">

**Author:** ![adminunix](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@adminunix](https://discuss.elastic.co/u/adminunix)\
**Post date:** [May 6, 2026, 3:41pm UTC](https://discuss.elastic.co/t/after-upgrade-to-9-3-4-problem-with-version-conflict-engine-exception/386162/4 "2026-05-06T15:41:39Z")

</div>

Hello,

Elastic Agent version 9.4.0 is released. I updated to it and the error has gone.

I think there is another error at last versions of Elasticsearch integration related to the monitoring data\_stream "metrics-elasticsearch.stack\_monitoring.index-default". I'll open a consultation for that.

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/a/f/afa9f7bdb9bd525c487330ce662fcc0a3792a410.png)

Thanks you very much.  
Regards

---

<div class="post-metadata">

**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\
**Post date:** [May 6, 2026, 7:53pm UTC](https://discuss.elastic.co/t/after-upgrade-to-9-3-4-problem-with-version-conflict-engine-exception/386162/5 "2026-05-06T19:53:38Z")

</div>

We have actually been seeing similar `version_conflict_engine_exception` behaviour in Logstash ingestion paths for quite a long time already. In the cases I investigated, the document was already indexed successfully and the retry itself causes the duplicate conflict. I'm not 100 % sure why this is happening, but I think we can ignore this.
