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 org.elasticsearch.server@9.2.0/org.elasticsearch.common.compress.CompressorFactory.compressor(CompressorFactory.java:43)
at org.elasticsearch.server@9.2.0/org.elasticsearch.common.xcontent.XContentHelper.createParser(XContentHelper.java:123)
at org.elasticsearch.server@9.2.0/org.elasticsearch.index.mapper.DocumentParser.parseDocument(DocumentParser.java:89)
at org.elasticsearch.server@9.2.0/org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:128)
at org.elasticsearch.server@9.2.0/org.elasticsearch.index.shard.IndexShard.prepareIndex(IndexShard.java:1087)
at org.elasticsearch.server@9.2.0/org.elasticsearch.index.shard.IndexShard.applyIndexOperation(IndexShard.java:1014)
at org.elasticsearch.server@9.2.0/org.elasticsearch.index.shard.IndexShard.applyIndexOperationOnPrimary(IndexShard.java:958)
at org.elasticsearch.server@9.2.0/org.elasticsearch.action.bulk.TransportShardBulkAction.executeBulkItemRequest(TransportShardBulkAction.java:420)
at org.elasticsearch.server@9.2.0/org.elasticsearch.action.bulk.TransportShardBulkAction$2.doRun(TransportShardBulkAction.java:277)
at org.elasticsearch.server@9.2.0/org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:27)
at org.elasticsearch.server@9.2.0/org.elasticsearch.action.bulk.TransportShardBulkAction.performOnPrimary(TransportShardBulkAction.java:345)
at org.elasticsearch.server@9.2.0/org.elasticsearch.action.bulk.TransportShardBulkAction.dispatchedShardOperationOnPrimary(TransportShardBulkAction.java:182)
at org.elasticsearch.server@9.2.0/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.
When indexing documents with invalid xcontent, compressor detection returns a
NotXContentExceptionwhich bubbles up as 500 / rest suppressed error. This is a client error and should be a 400 response code instead.In
CompressorFactory.compressor, we shouldn't be guessing the xContent type if that is already known inXContentHelper.createParser. That way this would correctly result in a parser error.Additionally we might consider having
NotXContentExceptionextendXContentParseException, so this results in a 400 status on other legacy code paths as well where we guess the xcontent type.