-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
feat(workflow_engine): Refactor the Data Condition Validator #88050
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
Conversation
…add support for comparison schema validation
|
||
comparison = serializers.JSONField(required=True) | ||
condition_result = serializers.JSONField(required=True) | ||
# condition_group_id = serializers.IntegerField(required=True) |
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.
fyi, this is on purpose. need to think through the data condition group a little more in another PR then think about how this ties together. I think in general, it's correct that we would just want the ID at this point.
Codecov ReportAttention: Patch coverage is ✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## master #88050 +/- ##
===========================================
+ Coverage 51.71% 87.77% +36.05%
===========================================
Files 9914 10016 +102
Lines 563395 568062 +4667
Branches 22208 22208
===========================================
+ Hits 291358 498613 +207255
+ Misses 271635 69047 -202588
Partials 402 402 |
…data condition validator. base condition validator now provides more
… SOLID design for metric alert comparison with new base
src/sentry/incidents/endpoints/validators/numeric_comparison_validator.py
Outdated
Show resolved
Hide resolved
src/sentry/incidents/endpoints/validators/numeric_comparison_validator.py
Outdated
Show resolved
Hide resolved
src/sentry/workflow_engine/endpoints/validators/base/data_condition_group.py
Outdated
Show resolved
Hide resolved
|
||
class BaseDataConditionGroupValidator(CamelSnakeSerializer): | ||
logic_type = serializers.CharField(required=True) | ||
organization_id = serializers.IntegerField(required=True) |
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.
do we need to validate that this is a real organization id? i think project/org is usually left out of the serializer because we validate the project/org based on the url path param, and we pass it as context
instead
sentry/src/sentry/api/endpoints/project_rules.py
Lines 753 to 755 in 9090ac8
serializer = DrfRuleSerializer( | |
context={"project": project, "organization": project.organization}, data=request.data | |
) |
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.
👍 yeah, i saw some of those too. can update to follow that pattern. (there are so many patterns for these in our codebase it's hard to tell what is "right" 😅)
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.
Yeah, that's a common pattern, although we could also build an OrganizationField
or something if we need to validate in this class
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'll address in a separate PR for the Groups 👍 -- this is just moving the code out of the data_condition
file and giving it a new home :)
src/sentry/incidents/endpoints/validators/numeric_comparison_validator.py
Outdated
Show resolved
Hide resolved
src/sentry/workflow_engine/endpoints/validators/base/data_condition.py
Outdated
Show resolved
Hide resolved
conditions = serializers.ListField(required=True) | ||
|
||
def validate_conditions(self, value): | ||
MetricAlertComparisonConditionValidator(data=value, many=True).is_valid( |
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.
Does it make sense do define this many=True
behaviour on the base class, and define the validator as a property? Or do you think there will be more customizations to validate_conditions
in the future that don't fit this model?
As an example of what I mean, in BaseDataConditionGroupValidator
we could do
def validate_conditions(self, value) -> list:
self.validator(data=value, many=True).is_valid(raise_exception=True)
Then we wouldn't need to define this at all on this subclass. Not sure if the validator needs to explicitly implement something to support many
?
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.
agree -- this was just to fix some mypy typing issues - hoping to address the DataConditionGroup
stuff in a separate PR, but wanted to move it away from the DataCondition code and there was a little bit of extra fallout 😅
|
||
class BaseDataConditionGroupValidator(CamelSnakeSerializer): | ||
logic_type = serializers.CharField(required=True) | ||
organization_id = serializers.IntegerField(required=True) |
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.
Yeah, that's a common pattern, although we could also build an OrganizationField
or something if we need to validate in this class
…ition and updated implementation of the detector condition. refocused pr to data condition and removed some things around data condition groups
…he validate condition results shared method
|
||
return value | ||
|
||
|
||
class BaseActionValidator(CamelSnakeModelSerializer[T], Generic[T]): |
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 fyi, my plan is to come back in another PR to restructure this + the data condition group stuff, once we hammer down a format in this PR.
src/sentry/workflow_engine/endpoints/validators/base/data_condition.py
Outdated
Show resolved
Hide resolved
class BaseDataConditionValidator( | ||
AbstractDataConditionValidator[Any, Any], | ||
): |
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 to make sure i understand, this validator is for any condition that is not one of the CONDITION_OPS
, conditions that use something in CONDITION_OPS
will implement AbstractDataConditionValidator
like MetricAlertComparisonConditionValidator
?
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.
💯 yeah - yuuup. this BaseDataConditionValidator
will respond to any custom handler. if we don't have a custom handler and it's just a condition op, you only need to setup the validator in the API layer using this.
PS, i am planning to change the BaseDataConditionValidator
name to DataConditionValidator
in a future pr to help with any confusion around it. Base
reads like it should be extended to me, and in this case, it's the generic implementation. i figured the diff was big enough on this PR already though.
organization_id = serializers.IntegerField(required=True) | ||
conditions = BaseDataConditionValidator(many=True) | ||
try: | ||
return validate_json_schema(value, handler.condition_result_schema) |
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.
need to make a task to add these for each handler, should they be enforced in the pre-save signal too? 😅
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.
yeah - another area i'm trying to limit scope of the PR to. This was mostly to confirm it works.
…ition.py Co-authored-by: Cathy Teng <[email protected]>
## Description - Separate the DataCondition and DataConditionGroup validators - Add tests to the BaseDataConditionGroupValidator - Add tests for BaseDataConditionValidator - Create `AbstractDataConditionValidator` to easily allow definitions, this meant we could completely remove the numeric validator as we can just use the abstract validator. --------- Co-authored-by: Cathy Teng <[email protected]>
Description
AbstractDataConditionValidator
to easily allow definitions, this meant we could completely remove the numeric validator as we can just use the abstract validator.