view surrounding documents link from discover app is throwing errors with date_nanos format

[avstri]

Kibana version: 7.7.1

Elasticsearch version: 7.7.1

Server OS version: Windows Server 2016 x64

Browser version: Chrome 83.0.4103.97 (Official Build) (64-bit)

Browser OS version: Windows 10

Original install method (e.g. download page, yum, from source, etc.): download page

Describe the bug: if time field is of type date_nanos then clicking view surround documents on discover produces a single line with a number of "shards failed" errors,

Steps to reproduce:

1. Open Discover tab in Kibana
2. Select an index pattern that has with time field in date_nanos
3. Click Refresh
4. Expand on any row below
5. Click "View Surrounding Documents"
6. Observe single document on the new tab page and multiple shards failed errors

Expected behavior:
New tab should open and show selected document and 5 that occured right before it and 5 right after it, temporarily disabling all filtering.

Screenshots (if relevant):

Errors in browser console (if relevant):
Type
parse_exception
Reason
failed to parse date field [159227450892987-07:] with format [strict_date_optional_time||epoch_millis]: [failed to parse date field [159227450892987-07:] with format [strict_date_optional_time||epoch_millis]]
Caused by type
illegal_argument_exception
Caused by reason
failed to parse date field [159227450892987-07:] with format [strict_date_optional_time||epoch_millis]
Caused by caused by type
date_time_parse_exception
Caused by caused by reason
Failed to parse with all enclosed parsers

---

request:
{
"size": 5,
"search_after": [
"159227450892987-07:",
48594383
],
"sort": [
{
"SourceTime": {
"order": "asc",
"unmapped_type": "boolean"
}
},
{
"_doc": {
"order": "asc",
"unmapped_type": "boolean"
}
}
],
"version": true,
"stored_fields": [
"*"
],
"script_fields": {},
"docvalue_fields": [
{
"field": "LogServerTime",
"format": "strict_date_time"
},
{
"field": "SourceTime",
"format": "strict_date_time"
}
],
"_source": {
"excludes": []
},
"query": {
"bool": {
"must": [
{
"constant_score": {
"filter": {
"range": {
"SourceTime": {
"format": "strict_date_optional_time",
"gte": "2020-06-16T02:28:28.92987-07:00Z",
"lte": "2020-06-17T02:28:28.92987-07:00Z"
}
}
}
}
}
],
"filter": [],
"should": [],
"must_not": []
}
}
}

Response:
{
"took": 16,
"timed_out": false,
"_shards": {
"total": 4,
"successful": 3,
"skipped": 3,
"failed": 1,
"failures": [
{
"shard": 0,
"index": "xxxx.xxx-000004",
"node": "cRSDEuywTT-6J9sR39_cMQ",
"reason": {
"type": "parse_exception",
"reason": "failed to parse date field [159227450892987-07:] with format [strict_date_optional_time||epoch_millis]: [failed to parse date field [159227450892987-07:] with format [strict_date_optional_time||epoch_millis]]",
"caused_by": {
"type": "illegal_argument_exception",
"reason": "failed to parse date field [159227450892987-07:] with format [strict_date_optional_time||epoch_millis]",
"caused_by": {
"type": "date_time_parse_exception",
"reason": "Failed to parse with all enclosed parsers"
}
}
}
}
]
},
"hits": {
"total": 0,
"max_score": 0,
"hits": []
}
}

Provide logs and/or server output (if relevant):

Any additional context:
I suspect that "search_after" parameter is incorrect, it is part epoch and part date (looks like 92987 is the microsecond portion and -07: is part of original time zone information).

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[timroes]

cc @kertal

[kertal]

this sounds like an issue in ES elastic/elasticsearch#52424

[timroes]

This has been closed in Elasticsearch in 7.10.0 and now works fine (revalidated the behavior in Kibana).