feat(crons): Report "true" transition timestamp in DecisionResult#80864
Merged
evanpurkhiser merged 1 commit intoNov 15, 2024
Conversation
JoshFerge
reviewed
Nov 15, 2024
JoshFerge
reviewed
Nov 15, 2024
JoshFerge
reviewed
Nov 15, 2024
JoshFerge
reviewed
Nov 15, 2024
9e29855 to
905090d
Compare
When transition into and out of an incident we want to know the _true_ start time and true recovery time of the incident. We can do this with the following logic: - When starting an incident we backfill the ABNORMAL decisions to INCIDENT. Record the timestamp of the very first abnormal and report that back with the DecisionResult that is transition=INCIDENT_STARTED - When recovering from an incident we backfill the RECOVERING decisions as NORMAL. Record the timestamp of the very first normal decision and report that back with the DecisionResult that is transition=INCIDENT_RECOVERED For all other decisions (including abnormal recovery and incident recovery failed) the timestamp is always just the tick that we're making the decision for, since these do not have The resulting time range is an inclusive start and exclusive end to determine the datetime range of the incident.
905090d to
b6cf28b
Compare
Codecov ReportAttention: Patch coverage is ✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## master #80864 +/- ##
==========================================
- Coverage 78.42% 78.42% -0.01%
==========================================
Files 7211 7211
Lines 319706 319718 +12
Branches 44004 44005 +1
==========================================
+ Hits 250716 250725 +9
- Misses 62601 62609 +8
+ Partials 6389 6384 -5 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When transition into and out of an incident we want to know the true start time and true recovery time of the incident. We can do this with the following logic:
When starting an incident we backfill the ABNORMAL decisions to INCIDENT. Record the timestamp of the very first abnormal and report that back with the DecisionResult that is transition=INCIDENT_STARTED
When recovering from an incident we backfill the RECOVERING decisions as NORMAL. Record the timestamp of the very first normal decision and report that back with the DecisionResult that is transition=INCIDENT_RECOVERED
For all other decisions (including abnormal recovery and incident recovery failed) the timestamp is always just the tick that we're making the decision for, since these do not have
The resulting time range is an inclusive start and exclusive end to determine the datetime range of the incident.
Part of GH-79328