Closed
Description
I noticed the following entry on Elasticsearch logs:
java.time.DateTimeException: Field Year cannot be printed as the value 273414 exceeds the maximum print width of 4
at java.base/java.time.format.DateTimeFormatterBuilder$NumberPrinterParser.format(DateTimeFormatterBuilder.java:2926)
at java.base/java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format(DateTimeFormatterBuilder.java:2529)
at java.base/java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format(DateTimeFormatterBuilder.java:2529)
at java.base/java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format(DateTimeFormatterBuilder.java:2529)
at java.base/java.time.format.DateTimeFormatter.formatTo(DateTimeFormatter.java:1905)
at java.base/java.time.format.DateTimeFormatter.format(DateTimeFormatter.java:1879)
at [email protected]/org.elasticsearch.common.time.JavaTimeDateTimePrinter.format(JavaTimeDateTimePrinter.java:46)
at [email protected]/org.elasticsearch.common.time.JavaDateFormatter.format(JavaDateFormatter.java:239)
at [email protected]/org.elasticsearch.search.DocValueFormat$DateTime.format(DocValueFormat.java:279)
at [email protected]/org.elasticsearch.search.DocValueFormat$DateTime.format(DocValueFormat.java:284)
at [email protected]/org.elasticsearch.search.DocValueFormat$DateTime.format(DocValueFormat.java:214)
at [email protected]/org.elasticsearch.search.aggregations.metrics.InternalStats.doXContentBody(InternalStats.java:228)
Which can be easily reproduce with the following sequence of commands:
PUT /test_date
{
"mappings": {
"properties": {
"date_field": {
"type": "date",
"format": "date_hour_minute_second_millis"
}
}
}
}
POST test_date/_doc
{
"date_field" : "9999-01-01T00:00:00.000"
}
POST test_date/_doc
{
"date_field" : "9999-01-01T00:00:00.000"
}
GET test_date/_search
{
"size": 0,
"aggs": {
"stats": {
"stats": {
"field": "date_field"
}
}
}
}
The issue is that chunked x-content serialization assumes that we don't throw exceptions at that point so we end up returning a 502 response t o the user in the case above. We should handle this case more gracefully and return a proper exception to the user.
similar to #95037