Check that data passed to Document is an associative array, not just an array

[dkarlovi]

If you do

$type->addDocuments([
    // note: no keys for properties in $data
    new Document(1, ['abc', 'bcd']),
    new Document(2, ['abc', 'bcd']),
]);

it's allowed by the library, but you'll get an exception failed to parse with a very cryptic reason:

"type":"not_x_content_exception",
"reason":"Compressor detection can only be called on some xcontent bytes or compressed xcontent bytes"

Reason is, you're not sending JSON objects in bulk, you're sending JSON arrays (which ES doesn't like):

{"index":{"_index":"index","_type":"type","_id":1}}
['abc', 'bcd']
{"index":{"_index":"index","_type":"type","_id":2}}
['abc', 'bcd']

It's quite a stupid error on the developer's (mine) part, but it still was quite an undertaking to find it. Could easily check for this when setting $data.

At least this will make a good Google search hit. :)

[p365labs]

Which version of ES are you using ?
Anyway you're right. The exception returned by ES it's not completely clear. I created a small test in order to find the Exception, this is the full exception returned from ES with the test case you show:

array(3) {
  ["type"]=>
  string(24) "mapper_parsing_exception"
  ["reason"]=>
  string(15) "failed to parse"
  ["caused_by"]=>
  array(2) {
    ["type"]=>
    string(23) "not_x_content_exception"
    ["reason"]=>
    string(91) "Compressor detection can only be called on some xcontent bytes or compressed xcontent bytes"
  }
}

I agree with you that not_x_content_exception it's a bit confusing, but failed to parse it's absolutely clear. The problem with the query is that the Document is not well formed, it should be an associative array. That's the way a Document should be. If you give a look to ES documentation you will see in Buld, or even in Index API that field names and values are strings and this is an associative array :)

Again you're right saying that it should be an associative array and not an indexed array... unfortunately in PHP there's no difference.

PHP arrays can contain integer and string keys at the same time as PHP does not distinguish between indexed and associative arrays.

[dkarlovi]

Which version of ES are you using ?

5.6.3 Docker image.

I agree with you that not_x_content_exception it's a bit confusing, but failed to parse it's absolutely clear.

I only partially agree here. Failed to parse - which part?

The problem got worse by the fact I tried to send the (faulty) document to be stored individually (so, no bulk). This gave me some weird errors about missing Content-Type (it seems Elastica doesn't send one) which caused me to go down the "debug transport" route and indeed, the Content-Type header is missing. This made me test other transport adapters, other versions of Elastica, etc.

I know it's supposed to be assoc array, my problem was that I'm generating the documents and haven't done so properly (as I said, this is no doubt my stupid mistake, can't run from the facts 😭 ).

Problem is, the feedback to my mistake was quite unclear or even misleading (the header bit), it wasn't something you can glance, slap your forehead and fix in 10sec.

That's why I'm proposing to make the feedback better since the one received from ES is not stellar.

[p365labs]

Ok now I have a more clear understand of your problem... and yes I agree with you that "failed to parse" is a bit generic, but that is on the shoulder of Elasticsearch. I mean the error is coming from Elasticsearch, which returns it to Elasticsearch-php which Elastica get and return as a ReponseException (in your specific case Bulk\ResponseException).

[dkarlovi]

@p365labs you're suggesting this should be reported to Elasticsearch?