view surrounding documents link from discover app is throwing errors with date_nanos format #69232
Labels
bug
Fixes for quality problems that affect the customer experience
Feature:Discover
Discover Application
Team:Visualizations
Visualization editors, elastic-charts and infrastructure
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:
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).
The text was updated successfully, but these errors were encountered: