-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
✨ feat(aci): create metric issue evidence dataclass #90562
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ feat(aci): create metric issue evidence dataclass #90562
Conversation
src/sentry/incidents/grouptype.py
Outdated
class MetricAlertDetectorHandler(StatefulDetectorHandler[QuerySubscriptionUpdate]): | ||
def build_occurrence_and_event_data( | ||
self, group_key: DetectorGroupKey, new_status: PriorityLevel | ||
) -> tuple[DetectorOccurrence, dict[str, Any]]: | ||
# Returning a placeholder for now, this may require us passing more info | ||
evidence_data = MetricIssueEvidenceData( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we add this dataclass on the StatefulDetectorHandler
itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually maybe even on the MetricIssue
grouptype? - i am trying to think of a better way to couple the concept of the evidence data format to the group itself
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, yeah, I feel like this code should be done elsewhere internally on the platform (at least parts of it) - then we can keep the alert id lookup in this code and pass it to the issue occurrence building through detector occurrence.
Because of that, maybe we put it with the detector occurrence code?
--
FYI, I'm working on a refactor to make the handler code a bit more composed and then I think this will probably be part of that. Maybe we can keep it simple to validate all the typing and then I can update it with the refactor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i decided to just keep the dataclass in this pr so i can use it later on, ill defer to hooking it up for your refactors
Codecov ReportAll modified and coverable lines are covered by tests ✅ ✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## master #90562 +/- ##
===========================================
+ Coverage 33.00% 87.84% +54.84%
===========================================
Files 8693 10265 +1572
Lines 484193 580847 +96654
Branches 22569 22569
===========================================
+ Hits 159797 510253 +350456
+ Misses 323963 70161 -253802
Partials 433 433 |
ad6e596
to
a5d4ddc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just the nit around moving some fields. i'm also okay with us using this as a quick definition then i'll update when i refactor.
src/sentry/incidents/grouptype.py
Outdated
detector_id: int | ||
alert_id: int | ||
data_condition_ids: list[int] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 can we have the detector_id
and data_condition_ids
on the EvidenceData class? (my thought is anything related to workflow engine that can be done in the abstraction can also be hidden away in the platform)
a5d4ddc
to
71d52c5
Compare
defining what we want the evidence data based on this doc.