NotXContentException on invalid xcontent should not cause 500 errors #131605
Description
When indexing documents with invalid xcontent, compressor detection returns a NotXContentException which bubbles up as 500 / rest suppressed error. This is a client error and should be a 400 response code instead.
org.elasticsearch.common.compress.NotXContentException: Compressor detection can only be called on some xcontent bytes or compressed xcontent bytes
at [email protected]/org.elasticsearch.common.compress.CompressorFactory.compressor(CompressorFactory.java:43)
at [email protected]/org.elasticsearch.common.xcontent.XContentHelper.createParser(XContentHelper.java:123)
at [email protected]/org.elasticsearch.index.mapper.DocumentParser.parseDocument(DocumentParser.java:89)
at [email protected]/org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:128)
at [email protected]/org.elasticsearch.index.shard.IndexShard.prepareIndex(IndexShard.java:1087)
at [email protected]/org.elasticsearch.index.shard.IndexShard.applyIndexOperation(IndexShard.java:1014)
at [email protected]/org.elasticsearch.index.shard.IndexShard.applyIndexOperationOnPrimary(IndexShard.java:958)
at [email protected]/org.elasticsearch.action.bulk.TransportShardBulkAction.executeBulkItemRequest(TransportShardBulkAction.java:420)
at [email protected]/org.elasticsearch.action.bulk.TransportShardBulkAction$2.doRun(TransportShardBulkAction.java:277)
at [email protected]/org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:27)
at [email protected]/org.elasticsearch.action.bulk.TransportShardBulkAction.performOnPrimary(TransportShardBulkAction.java:345)
at [email protected]/org.elasticsearch.action.bulk.TransportShardBulkAction.dispatchedShardOperationOnPrimary(TransportShardBulkAction.java:182)
at [email protected]/org.elasticsearch.action.bulk.TransportShardBulkAction.dispatchedShardOperationOnPrimary(TransportShardBulkAction.java:83)
In CompressorFactory.compressor, we shouldn't be guessing the xContent type if that is already known in
XContentHelper.createParser. That way this would correctly result in a parser error.
Additionally we might consider having NotXContentException extend XContentParseException, so this results in a 400 status on other legacy code paths as well where we guess the xcontent type.