Cover more incident creation scenarions
- Dominant language
- Python
- Stars
- 44.8k
- Forks
- 4.9k
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 624
Description
Thread for context: https://github.com/getsentry/sentry/pull/59445/files#r1394889657
There are a number of cases for monitor incident creation we don't currently handle correctly. This ticket documents those cases. There are likely more but for now this is what we've considered:
Key for cases
```
X = failed
I = in-progress
O = OK
```
### Unhandled incident creation cases
1. ```
X X I X X
```
could very well turn into this
```
X X O X X
```
In this scenario we would want to NOT create an incident since even though there were 4 failures with an in-progress in the middle (That we're ignoring right now), this still ended up not being an incident since it resolved with OK.
2. ```
failure_threshold=4
recovery_threshold=4
X X I X X O O
```
In this scenario imagine the 3rd check-in becomes a failure, when this happens we would have met the recovery threshold. However, when determining incidents we only look at the 4 most recent check-ins, since that's the failure threshold, because of that the 2 OK check-ins would cause us NOT to see this as an incident.
Contributor guide
Assessment
This issue has not been assessed yet.