Unexpected behaviour for min - max aggregations on date_nanos type

[viglia]

Describe the feature:

Elasticsearch version (bin/elasticsearch --version): 7.6.0-SNAPSHOT

build_hash : "6653ed095a2fa342c9f58ddefd03dd47fb72b5d7",

build_date : "2020-02-11T02:35:28.882468Z",

Plugins installed: [repository-gcs-7.6.0-SNAPSHOT.zip]

JVM version (java -version): openjdk version "12.0.2"

OS version (uname -a if on a Unix-like system): 17.7.0 Darwin Kernel Version 17.7.0: Sun Jun 2 20:31:42 PDT 2019; root:xnu-4570.71.46~1/RELEASE_X86_64 x86_64

Description of the problem including expected versus actual behavior:

Computing the min and max aggregations on a date_nanos field produce an unexpected "value_as_string" string representation value.

If a query range is added to manually specify the upper limit, the problem does not arise.

Steps to reproduce:

Please include a minimal but complete recreation of the problem, including
(e.g.) index creation, mappings, settings, query etc. The easier you make for
us to reproduce it, the more likely that somebody will take the time to look at it.

PUT /test
{
    "settings" : {
        "number_of_shards" : 1
    },
    "mappings" : {
        "properties" : {
        "@timestamp" : {
          "type" : "date_nanos",
          "format" : "yyyy-MM-dd HH:mm:ss.SSSSSSSSS"
        }
        }
    }
}

PUT /test/_doc/1
{
  "@timestamp": "2015-01-01 00:10:00.838000000"
}

PUT /test/_doc/2
{
  "@timestamp": "2016-01-01 00:00:00.575000000"
}

GET /test/_search
{
  "size": 0, 
  "aggs": {
    "min": {
      "min": {
        "field": "@timestamp"
      }
    },
    "max" : {
      "max": {
        "field": "@timestamp"
      }
    }
  }
}

this produces the following output:

{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 2,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  },
  "aggregations" : {
    "min" : {
      "value" : 1.42007100083800013E18,
      "value_as_string" : "+45002228-08-10 03:26:40.128000000"
    },
    "max" : {
      "value" : 1.45160640057500006E18,
      "value_as_string" : "+46001545-08-23 15:43:20.064000000"
    }
  }
}

4. Now, if we add a range

GET /test/_search
{
  "size": 0, 
  "query": {
    "range": {
      "@timestamp": {
        "lte": "2016-01-01 00:00:00.575000000"
      }
    }
  }, 
  "aggs": {
    "min": {
      "min": {
        "field": "@timestamp"
      }
    },
    "max" : {
      "max": {
        "field": "@timestamp"
      }
    }
  }
}

We get the right values:

{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 2,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  },
  "aggregations" : {
    "min" : {
      "value" : 1.420071000838E12,
      "value_as_string" : "2015-01-01 00:10:00.838000000"
    },
    "max" : {
      "value" : 1.451606400575E12,
      "value_as_string" : "2016-01-01 00:00:00.575000000"
    }
  }
}

Provide logs (if relevant):

[elasticmachine]

Pinging @elastic/es-analytics-geo (:Analytics/Aggregations)

[nik9000]

I was just looking at these fields this morning so I'll have a look at this too.

[polyfractal]

Drive-by comment: could be related to the BKD optimization in the min/max aggregators, because that is disabled if there is a query (among other things) which might explain the different behavior

[nik9000]

Drive-by comment: could be related to the BKD optimization in the min/max aggregators, because that is disabled if there is a query (among other things) which might explain the different behavior

You are dead on. I believe I've fixed it. Now just got to make a test!