feat(workflow_engine): Refactor the Data Condition Validator

[saponifi3d]

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.

[saponifi3d]

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]

Codecov Report

Attention: Patch coverage is 92.12963% with 17 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...engine/endpoints/validators/base/data_condition.py	78.72%	10 Missing ⚠️
src/sentry/incidents/metric_alert_detector.py	85.71%	4 Missing ⚠️
...oints/validators/test_base_data_condition_group.py	85.00%	3 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #88050       +/-   ##
===========================================
+ Coverage   51.71%   87.77%   +36.06%     
===========================================
  Files        9914    10000       +86     
  Lines      563395   567077     +3682     
  Branches    22208    22208               
===========================================
+ Hits       291358   497767   +206409     
+ Misses     271635    68908   -202727     
  Partials      402      402               

[cathteng]

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
	)

[saponifi3d]

👍 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" 😅)

[wedamija]

Yeah, that's a common pattern, although we could also build an OrganizationField or something if we need to validate in this class

[saponifi3d]

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 :)

[wedamija]

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?

[saponifi3d]

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 😅

[wedamija]

Yeah, that's a common pattern, although we could also build an OrganizationField or something if we need to validate in this class

[saponifi3d]

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.