500 when inserting wrong elastic type

[sgulseth]

[Wed Dec 09 09:02:01 2015] [error] [client 10.84.100.151] PHP Fatal error: Uncaught Exception with message: {"error":"MapperParsingException[failed to parse [metadata.date]]; nested: MapperParsingException[failed to parse date field [false], tried both date format [dateOptionalTime], and timestamp number with locale []]; nested: IllegalArgumentException[Invalid format: "false"]; ","status":400} in /services/applications/imbo/vendor/imbo/imbo/public/index.php on line 25

[christeredvartsen]

@fangel Do you know if this is still an issue after upgrading clients / servers?

[fangel]

I'm unsure - nothing was changed with how we deal with exceptions coming back from the Elastic client.

It might happen if you post some metadata for one field of a fairly strict type that Elastic infers - looks like that was a date-field in the above case. If you then post more metadata for the same field, that doesn't fit this type - then you might get an exception. But I haven't tested this theory.

So if my theory is correct, then you need to do something like

1. Post metadata to an image with {"date": "2017-04-11T07:55:00Z"}
2. Post metadata for another image with {"date": false}

Now Elastic should have used the first piece of metadata to infer that the date-field was of type date, and then by the second piece, it will fail because it fails to parse false as a date (so if the intent was to signal a missing date - null should have been used).

I'll try and reproduce later. But I don't know what the best way to handle this is.

I think actually keeping an error in place when you try and push the second piece of metadata is appropriate. My reason is that we failed to actually index the Metadata, so none of the images metadata will be searchable, which is an error - and it was caused by the user-provided data.