feat(aci): add alertrule/workflow GET endpoint

[ameliahsu]

used to get a rule/alert rule for a given workflow id or vice versa, for redirecting urls

[codecov]

Codecov Report

❌ Patch coverage is 98.33333% with 1 line in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
..._engine/endpoints/validators/alertrule_workflow.py	90.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #97351   +/-   ##
=======================================
  Coverage   80.66%   80.66%           
=======================================
  Files        9202     9205    +3     
  Lines      393026   393087   +61     
  Branches    25001    25001           
=======================================
+ Hits       317022   317082   +60     
- Misses      75579    75580    +1     
  Partials      425      425           

[seer-by-sentry]

Potential bug: Using `CharField` for ID fields in `AlertRuleWorkflowValidator` allows non-numeric strings, causing a `ValueError` and server crash in the ORM filter.

• Description: The AlertRuleWorkflowValidator defines rule_id, alert_rule_id, and workflow_id as serializers.CharField. This allows non-numeric strings to pass validation. However, when these string values are used in the ORM filter, the underlying BoundedBigIntegerField model fields attempt to cast the string to an integer via int(value). If a non-numeric string like "abc" is provided in the query parameters, this cast raises a ValueError, leading to an unhandled exception and an HTTP 500 server error.
• Suggested fix: Change the validator fields rule_id, alert_rule_id, and workflow_id in AlertRuleWorkflowValidator from serializers.CharField to serializers.IntegerField. This will ensure that only numeric values are accepted, providing proper validation upfront and preventing the ValueError in the ORM layer.
  _{severity: 0.7, confidence: 0.95}

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[ceorourke]

Alternately I think you could do this in one filter like (this might not be totally correct):

from django.db.models import Q

alert_rule_workflow = AlertRuleWorkflow.objects.filter(
    workflow__organization=organization,
    Q(workflow_id=workflow_id) | Q(workflow_id=None),
    Q(alert_rule_id=alert_rule_id) | Q(alert_rule_id=None),
    Q(rule_id=rule_id) | Q(rule_id=None),
).first()

[ceorourke]

Or you could do some When stuff, tbh I haven't used this yet myself https://docs.djangoproject.com/en/5.2/ref/models/conditional-expressions/#when

[ameliahsu]

hm I think your suggestion actually filters for when workflow_id=workflow_id OR workflow_id=None, but what I want to do here is only filter on workflow_id if a workflow_id is specified by the user

[saponifi3d]

taking a step back, should we make this api? could we handle the redirect on the server side w/o making an API call?

I think we'd just need to make sure to use a full page nav vs a react-router in page only... although I was expecting the UI to only support the new models (detector / workflows) to avoid a lot of this complexity.

[ameliahsu]

@saponifi3d Unfortunately due to Slack retention I can't link the conversation, but this is the solution was agreed on for redirects. We decided that we wouldn't add alert_id to the workflow engine endpoints and we would do this instead.

[cursor]

Bug: Validation Fails, Returns Misleading Error.

The validator allows both rule_id and alert_rule_id to be provided simultaneously, but these fields are mutually exclusive according to the database constraint on AlertRuleWorkflow. When both are provided, the query will always return no results (404) instead of returning a proper validation error (400). The validator should reject requests where both rule_id and alert_rule_id are provided together.

 

[github-actions]

🚨 Warning: This pull request contains Frontend and Backend changes!

It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently.

Have questions? Please ask in the #discuss-dev-infra channel.