-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
feat(aci): Track DataCondition errors and propagate such results as tainted #103003
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
base: master
Are you sure you want to change the base?
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #103003 +/- ##
===========================================
+ Coverage 80.58% 80.82% +0.23%
===========================================
Files 8937 8948 +11
Lines 391228 391894 +666
Branches 24887 24887
===========================================
+ Hits 315277 316746 +1469
+ Misses 75581 74778 -803
Partials 370 370 |
|
TODO: document how DataConditions should handle failure. |
| if condition_results is not None and condition_results.logic_result.is_tainted(): | ||
| tainted = True | ||
|
|
||
| if condition_results is None or condition_results.logic_result.triggered is False: |
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.
Bug: Group Counter Resets Misdirected
enqueue_counter_reset() is called without passing group_key, causing it to reset counters for the default None group key instead of the current group being processed. This results in counter resets being applied to the wrong group when multiple groups are being evaluated.
DataCondition failures are currently reported to Sentry/logs individually, then treated as a non-triggering.
Here we return a special error type, so that the caller knows the result isn't necessarily reliable, and in DataConditionGroup logic we aggregate these results in such a way that we know at the end if an untrustworthy result influenced the outcome.
These "tainted" results are reported for each Detector evaluation, so we can track how often our results were influenced by errors, giving us a better high level picture of user impact than we'd have purely by looking at individual reported error counts.
This pattern will be extended to cover over DataCondition evaluation cases.