7.9 not allowing null_value in date type

[psanz-estc]

Elasticsearch version (bin/elasticsearch --version): 7.9.0

Plugins installed: []

JVM version (java -version):

OS version (uname -a if on a Unix-like system):

Description of the problem including expected versus actual behavior:

Steps to reproduce:

Before 7.9.0, null_value could be used when defining a date:

PUT testindex1
{
  "mappings": {
    "properties": {
      "testdate": {
        "type": "date",
        "null_value": "",
        "format": "dd/MM/yyyy HH:mm:ss"
      }
    }
  }
}

Output:

{
  "acknowledged" : true,
  "shards_acknowledged" : true,
  "index" : "testindex1"
}

In 7.9.0, using the same PUT command, we get an error:

   "type" : "mapper_parsing_exception",
    "reason" : "Failed to parse mapping [_doc]: cannot parse empty date",
    "caused_by" : {
      "type" : "illegal_argument_exception",
      "reason" : "cannot parse empty date"
    }

Using null_value with a keyword as shown in the documentation does work.

Provide logs (if relevant):

[elasticmachine]

Pinging @elastic/es-core-features (:Core/Features/Indices APIs)

[elasticmachine]

Pinging @elastic/es-search (:Search/Mapping)

[romseygeek]

This should still work in you pass in null rather than the empty string (assuming that the intention here is to have nothing added for null values). Currently it's trying to parse the empty string into a date.

I can update things so that empty strings are interpreted as no value, but I'm not sure how much sense that actually makes? If you want to not have a null value, don't set it in the mappings or pass in null.

[romseygeek]

Digging into this further: what actually happened previously here was that this error was occuring at index time, rather than at put mapping time, when a document with a null value for a date was encountered; presumably you weren't seeing this because you have ignore_malformed set to true, or because none of the input documents actually had null dates. So I don't think we should change this to not throw an error, but we should improve the error message to let you know which parameter is causing the problem.