[Security Solutions][Detection Engine] Fixes timestamp bugs within source indexes when the formats are not ISO8601 format#101349
Conversation
| "@timestamp": "2020-12-16T15:16:18.570Z", | ||
| "event": { | ||
| "ingested": "2020-12-16T15:16:18.570Z" | ||
| "ingested": "2020-12-16T16:16:18.570Z" |
There was a problem hiding this comment.
NOTE: Slight change just to ensure the tests still pass since event.ingested is usually a different value.
| "value": { | ||
| "index": "myfakeindex-3", | ||
| "mappings": { | ||
| "dynamic": "strict", |
There was a problem hiding this comment.
NOTE: Just added this to make sure I didn't add any bugs so it will blow up if it cannot insert the correct data.
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Reading through the gist referenced in the PR description my understanding is that the introduction of the field property into the query is overriding the formatting forced by the docvalue_fields which can lead to parsing error bugs. And that by moving the formatted timestamp / timestamp override fields (originally the docvalue_fields) into the field property we are able to continue to ensure proper formatting. This looks great! Thanks for catching this and the extra work around removing the ts-expect-error and the additional integration tests.
LGTM!
TL;DR from the gist:
Old and bad / buggy way
# Old and BAD because formatting doesn't stick
GET packetbeat*/_search
{
"size": 1,
"docvalue_fields": [
{
"field": "@timestamp",
"format": "YYYY"
}],
"fields": [
{"field": "*",
"include_unmapped": "true"
}
]
}
will return
"@timestamp" : [
"2021-06-04T21:07:21.951Z"
],
New and not buggy results
GET packetbeat*/_search
{
"size": 1,
"fields": [
{"field": "*",
"include_unmapped": "true"
},
{"field": "@timestamp",
"format": "YYYY"}
]
}
will result in
"@timestamp" : [
"2021"
],
| field: '*', | ||
| include_unmapped: true, | ||
| }, | ||
| ...docFields, |
| @@ -0,0 +1,208 @@ | |||
| /* | |||
There was a problem hiding this comment.
Thank you for moving these relevant tests into their own file!
| * partial errors happen correctly | ||
| */ | ||
| describe('timestamp tests', () => { | ||
| describe('Signals generated from events with a timestamp in seconds is converted correctly into the forced ISO8601 format when copying', () => { |
There was a problem hiding this comment.
💥 Tests for this formatting bug. Nice addition.
…urce indexes when the formats are not ISO8601 format (elastic#101349) ## Summary We have a few bugs where when the source index for detections is not `"strict_date_optional_time"` it is possible that we will misinterpret the format to be epoch milliseconds when it could be epoch seconds or another ambiguous format or blow up when trying to write out the signals index. This fixes it to where we query for the source index format as an ISO8601 and when we copy the date time format we copy it back out as ISO8601 and insert it into the signal index as ISO8601. See this [gist](https://gist.github.com/FrankHassanabad/f614ec9762d59cd1129b3269f5bae41c) for more details of how this was accidentally introduced when we added support for runtime fields and the general idea of the fix. * Removes `docvalue_field` and we now only use `fields` in detection engine search requests * Splits out the timestamp e2e tests into their own file for `timestamps` file * Adds more tests to ensure we copy what we expect and we are converting to ISO8601 in the signals * Removes `ts-expect-error` in a lot of areas including tests and then I fix the types and issues once it is removed. ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…urce indexes when the formats are not ISO8601 format (#101349) (#101440) ## Summary We have a few bugs where when the source index for detections is not `"strict_date_optional_time"` it is possible that we will misinterpret the format to be epoch milliseconds when it could be epoch seconds or another ambiguous format or blow up when trying to write out the signals index. This fixes it to where we query for the source index format as an ISO8601 and when we copy the date time format we copy it back out as ISO8601 and insert it into the signal index as ISO8601. See this [gist](https://gist.github.com/FrankHassanabad/f614ec9762d59cd1129b3269f5bae41c) for more details of how this was accidentally introduced when we added support for runtime fields and the general idea of the fix. * Removes `docvalue_field` and we now only use `fields` in detection engine search requests * Splits out the timestamp e2e tests into their own file for `timestamps` file * Adds more tests to ensure we copy what we expect and we are converting to ISO8601 in the signals * Removes `ts-expect-error` in a lot of areas including tests and then I fix the types and issues once it is removed. ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios Co-authored-by: Frank Hassanabad <frank.hassanabad@elastic.co>
* master: (90 commits) Fix UI breaks on providing long search keyword in 'Search Box' (elastic#101385) Adds css class to EuiDescriptionListDescription in order to break word on exception details card (elastic#101481) [Lens] Increase timings for drag and drop tests (elastic#101380) [Lens] Fix editor react error on configuration panel (elastic#101367) [Fleet] Move integrations to a separate app (elastic#99848) Fix incorrect message displayed on importing Timeline Templates (elastic#101288) [Cases] RBAC (elastic#95058) [APM] Visual improvements for new APM layout with left navigation (elastic#101360) [master] More precise alerts matching (elastic#99820) [Lens] Value in legend (elastic#101353) Revert "[Reporting] ILM policy for managing reporting indices (elastic#100130)" (elastic#101358) [Discover] Fix header row of data grid in Firefox (elastic#101374) Add link to advanced setting in Discover (elastic#101154) Url service locators (elastic#101045) [Timelion] Update the removal message to mention the exact version (elastic#100994) [Security Solution][Detection Engine] Test cases for alias failure test cases where we don't copy aliases correctly (elastic#101437) [Event Log] Adding `type_id` to saved object array in event log (elastic#100939) [Reporting] Add `location.url` info to console message logs (elastic#101427) [Security Solutions][Detection Engine] Fixes timestamp bugs within source indexes when the formats are not ISO8601 format (elastic#101349) Improve Task Manager instrumentation (elastic#99160) ...
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
Summary
We have a few bugs where when the source index for detections is not
"strict_date_optional_time"it is possible that we will misinterpret the format to be epoch milliseconds when it could be epoch seconds or another ambiguous format or blow up when trying to write out the signals index. This fixes it to where we query for the source index format as an ISO8601 and when we copy the date time format we copy it back out as ISO8601 and insert it into the signal index as ISO8601.See this gist for more details of how this was accidentally introduced when we added support for runtime fields and the general idea of the fix.
docvalue_fieldand we now only usefieldsin detection engine search requeststimestampsfilets-expect-errorin a lot of areas including tests and then I fix the types and issues once it is removed.Checklist