(fix): Sentry-16D3 - Issue accessing the project on a query subscription
Description
Error report: https://sentry.sentry.io/issues/4527458007/?project=1
Looks like this was missed after we migrated from projects being stored on the alert_rule. This can now be removed because all projects should exist at the alert_rule level.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 80.00%. Comparing base (
6ba3e18) to head (a89f1b9).
Additional details and impacted files
@@ Coverage Diff @@
## master #70835 +/- ##
==========================================
+ Coverage 79.02% 80.00% +0.98%
==========================================
Files 6507 6507
Lines 290838 290838
Branches 50126 50125 -1
==========================================
+ Hits 229844 232695 +2851
+ Misses 60558 57707 -2851
Partials 436 436
| Files | Coverage Δ | |
|---|---|---|
| ...dents/endpoints/organization_alert_rule_details.py | 97.08% <ø> (+0.67%) |
:arrow_up: |
What does it mean if there is no project? The sentry issue existed because that happened, is it ok to just pass when it's not found?
What does it mean if there is no project? The sentry issue existed because that happened, is it ok to just pass when it's not found?
If there's not a project associated with an alert, then the check for if the user has access to None project which will fail, and the user will be shown an error message related to that.
Previously, the failure was happening because the alert rule's snuba query was trying to access a subscription that didn't exist on an activated alert. This happens with activated alerts because they delay creating a snuba subscription until the activation event occurs. By removing the change to lookup the project id from the subscription and directly looking at the alert, we can avoid looking at subscriptions that may not exist yet.