Action_request_validation_exception: [action_request_validation_exception] Reason: Validation Failed: 1: id is missing

Elastic Stack Elasticsearch
1

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:

{
  "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:

+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.

2

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.

3

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.

4

Yeah. There's a limit to 512 bytes but I'd expect another error message than the one you reported in that case:

5

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.