# Action\_request\_validation\_exception: \[action\_request\_validation\_exception\] Reason: Validation Failed: 1: id is missing

**URL:** <https://discuss.elastic.co/t/action-request-validation-exception-action-request-validation-exception-reason-validation-failed-1-id-is-missing/383039>\
**Category:** Elasticsearch\
**Created:** [October 28, 2025, 9:38am UTC](https://discuss.elastic.co/t/action-request-validation-exception-action-request-validation-exception-reason-validation-failed-1-id-is-missing/383039 "2025-10-28T09:38:52Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![junqiang\_ma](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/junqiang_ma/32/101115_2.png) [@junqiang\_ma](https://discuss.elastic.co/u/junqiang_ma)\
**Post date:** [October 28, 2025, 9:38am UTC](https://discuss.elastic.co/t/action-request-validation-exception-action-request-validation-exception-reason-validation-failed-1-id-is-missing/383039/1 "2025-10-28T09:38:52Z")

</div>

We are using Elasticsearch 7.5.10 and indexing data into this cluster via a Node.js application (client version: `"@elastic/elasticsearch": "7.17"`). My index mapping is as follows:

```auto
{
  "platform.fund.notices.test_a": {
    "aliases": {},
    "mappings": {
      "_source": {
        "excludes": [
          "_",
          "deleteField",
          "flag"
        ]
      },
      "properties": {
        "COMPANYCODE": {
          "type": "keyword"
        },
        "FWDT": {
          "type": "date"
        },
        "Guid": {
          "type": "keyword"
        },
        "NW1303_001": {
          "type": "text",
          "analyzer": "contain"
        },
        "NW1303_007": {
          "type": "keyword",
          "index": false
        },
        "NW1303_008": {
          "type": "keyword"
        },
        "NW1303_009": {
          "type": "keyword"
        },
        "NW1313_002": {
          "type": "text",
          "index": false
        },
        "NW1313_004": {
          "type": "keyword",
          "doc_values": false
        },
        "NW1313_005": {
          "type": "keyword",
          "index": false
        },
        "PUBISHDATE": {
          "type": "date",
          "format": "yyyy-MM-dd||yyyyMMdd"
        },
        "_": {
          "type": "keyword",
          "index": false
        },
        "attachList": {
          "properties": {
            "DD0031_004": {
              "type": "keyword"
            },
            "DD0031_008": {
              "type": "keyword",
              "index": false
            }
          }
        },
        "flag": {
          "type": "byte",
          "index": false
        },
        "id": {
          "type": "keyword"
        },
        "noticeDate": {
          "type": "date",
          "format": "yyyy-MM-dd||yyyyMMdd"
        },
        "tNW1303": {
          "type": "nested",
          "properties": {
            "CO": {
              "type": "keyword"
            },
            "DD9205_002": {
              "type": "keyword",
              "index": false
            },
            "FinfoID": {
              "type": "keyword"
            },
            "SYMBOL": {
              "type": "keyword"
            },
            "TRCode": {
              "type": "keyword"
            },
            "fund_type": {
              "type": "keyword"
            },
            "fund_type2": {
              "type": "keyword"
            },
            "tNW1303_id": {
              "type": "keyword"
            }
          }
        },
        "typeList": {
          "properties": {
            "NW1303_005": {
              "type": "keyword"
            },
            "NW1303_006": {
              "type": "keyword",
              "index": false
            }
          }
        }
      }
    },
    "settings": {
      "index": {
        "max_ngram_diff": "29",
        "routing": {
          "allocation": {
            "include": {
              "_tier_preference": "data_content"
            }
          }
        },
        "refresh_interval": "-1",
        "number_of_shards": "3",
        "provided_name": "platform.fund.notices.test_a",
        "creation_date": "1761642015631",
        "analysis": {
          "analyzer": {
            "contain": {
              "stopwords": "_none_",
              "tokenizer": "contain"
            }
          },
          "tokenizer": {
            "contain": {
              "token_chars": [
                "letter",
                "digit",
                "punctuation"
              ],
              "min_gram": "1",
              "type": "ngram",
              "max_gram": "3"
            }
          }
        },
        "number_of_replicas": "1",
        "uuid": "FzR_Lx-hTY2pOVXCUWADXg",
        "version": {
          "created": "7100299"
        }
      }
    }
  }
}

```

We are using `uuid` as the document ID. During the data write process, we occasionally encounter the following error:

```auto
+08:00 2025-10-28 13:22:49 096: task:undefined-EsWriter ; cost:244 ms ; attempt:7 ; sleep:526000 ms ; index:platform.fund.notices.test_a/doc
+08:00 2025-10-28 13:22:49 096: ResponseError: action_request_validation_exception: [action_request_validation_exception] Reason: Validation Failed: 1: id is missing;
+08:00 2025-10-28 13:22:49 096: at Unzip.onBody [as cb] (/app/source_code/node_worker/node_modules/@elastic/elasticsearch/lib/Transport.js:375:23)
+08:00 2025-10-28 13:22:49 096: at Unzip.zlibBufferOnEnd (node:zlib:161:10)
+08:00 2025-10-28 13:22:49 096: at Unzip.emit (node:events:517:28)
+08:00 2025-10-28 13:22:49 096: at endReadableNT (node:internal/streams/readable:1400:12)
+08:00 2025-10-28 13:22:49 096: at process.processTicksAndRejections (node:internal/process/task_queues:82:21)

```

However, if we rerun the task, the data that previously caused the error can be written successfully.

An example of the `uuid` field is as follows:  
`id: 347cc063b9-b9b5a26215e4940669c72be16cfd1e55`

After we switched to using shorter Base64 values as the ID, this issue no longer occurs.

Could someone take a look at this when you have a moment? I’d really appreciate it.

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [October 28, 2025, 9:58am UTC](https://discuss.elastic.co/t/action-request-validation-exception-action-request-validation-exception-reason-validation-failed-1-id-is-missing/383039/2 "2025-10-28T09:58:17Z")

</div>

Welcome!

For whatever reason it seems that in some cases the `_id` field is not provided. I'd double check the code because I suspect the problem is there.  
May be add a logger to print whenever the computed id is empty, just before posting the request to Elasticsearch.

Without seeing your code, I can't really tell more...

BTW, 7.5 is totally outdated and has not been receiving the needed security patches.  
At the very least, you should upgrade to 7.17.29. But better to switch to 8.19 or 9.2.0.

---

<div class="post-metadata">

**Author:** ![junqiang\_ma](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/junqiang_ma/32/101115_2.png) [@junqiang\_ma](https://discuss.elastic.co/u/junqiang_ma)\
**Post date:** [October 29, 2025, 12:46am UTC](https://discuss.elastic.co/t/action-request-validation-exception-action-request-validation-exception-reason-validation-failed-1-id-is-missing/383039/3 "2025-10-29T00:46:34Z")

</div>

Thank you for your assistance. We performed a thorough review of the code and confirmed that every record written contains an **id** field. We also ran a test where we applied Base64 encoding to the original **guid** field and used that as the **id** , and the issue did not occur again.

We suspect that the problem may be related to the **guid** being too long, or that our **guid** generation pattern causes the prefix of the values to be identical, which could potentially lead to performance issues. As a next step, we are considering upgrading our ES version.

Once again, thank you very much for your suggestions.

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [October 29, 2025, 8:38am UTC](https://discuss.elastic.co/t/action-request-validation-exception-action-request-validation-exception-reason-validation-failed-1-id-is-missing/383039/4 "2025-10-29T08:38:34Z")

</div>

Yeah. [There's a limit to 512 bytes](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/mapping-id-field) but I'd expect another error message than the one you reported in that case:

> <https://github.com/elastic/elasticsearch/blob/dc8afd28c7f23d94b0317912a1cde4759eecc551/server/src/main/java/org/elasticsearch/action/DocWriteRequest.java#L342-L354>

---

<div class="post-metadata">

**Author:** ![junqiang\_ma](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/junqiang_ma/32/101115_2.png) [@junqiang\_ma](https://discuss.elastic.co/u/junqiang_ma)\
**Post date:** [October 30, 2025, 12:57am UTC](https://discuss.elastic.co/t/action-request-validation-exception-action-request-validation-exception-reason-validation-failed-1-id-is-missing/383039/5 "2025-10-30T00:57:00Z")

</div>

Thanks for the reminder. After encountering this issue, I carefully reviewed all document IDs and confirmed that their lengths are within the maximum size allowed for the `_id` field in Elasticsearch. Aside from being slightly longer than typical fields, containing hyphens, and some IDs potentially sharing the same prefix (the part before the hyphen), I currently can’t think of any other possible root causes.
