Elasticsearch: Missing ID for an update/delete operation causes the entire bulk to fail

[radu-gheorghe]

If one of the actions from a bulk requires an ID (update/delete) but doesn't have it, the entire bulk fails. For example:

$ cat /tmp/test_bulk 
{"index":{}}
{"name":"test doc"}
{"delete":{}}

$ curl -XPOST localhost:9200/test/test/_bulk?pretty --data-binary @/tmp/test_bulk
{
  "error" : "ActionRequestValidationException[Validation Failed: 1: id is missing;]",
  "status" : 400
}

I would expect the index operation to succeed and the delete/update operation to fail. Or maybe there's a good reason for failing the whole bulk that I don't see?

[clintongormley]

Hmm. This is a parse validation which happens during the initial parse phase, as opposed to when the bulk request has been divided up into mini-bulks and forwarded to all nodes to succeed or fail as appropriate.

I can understand why it fails as it does today, but from a client perspective it makes it a bit harder to decided what to do here i suppose...

[sherry-ger]

Version : ES 2.1.1

This also happens if the index does not exist. It seems all the bulk actions to the the index will fail instead of just the one that is malformed or with the incorrect syntax. The error message to each operation regardless of correctness is the same. Also, the index is not created. For example,

POST _bulk
{ "index" : { "_index" : "my_index", "_type" : "test", "_id" : "5" } }
{ "user" : "user5" } 
{ "index" : { "_index" : "my_index", "_type" : "", "_id" : "2" } }
{ "user" : "user2" } 
{ "delete" : { "_index" : "my_index", "_type" : "test", "_id" : "5" } }

Here are the error messages for all items.

{
  ...
  "error": {
    "type": "mapper_parsing_exception",
    "reason": "Failed to parse mapping []: mapping type name is empty",
    "caused_by": {
      "type": "invalid_type_name_exception",
      "reason": "mapping type name is empty"
    }
  }
}

This behavior is inconsistent with the documentation. Should the "correct" operations be successful?

[clintongormley]

Yeah, this is tricky. This is essentially a malformed request which is detected before the mini bulk requests are sent to the respective shards for processing. But I agree that it'd be nicer if these were handled in the same way as other errors.

[tomcallahan]

We discussed this in our FixItFriday meeting and determined that this is something we should do

[thinkdell01]

meanwhile what is workaround for this?

[henningandersen]

Similar to #24319 and #9379