fix(iswf): Updates the display label for alerts to use Workflow by default, when available#112887
fix(iswf): Updates the display label for alerts to use Workflow by default, when available#112887GabeVillalobos wants to merge 1 commit intomasterfrom
Conversation
…fault, when available
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix prepared a fix for the issue found in the latest run.
- ✅ Fixed: Unnecessary DB query for test notification workflow ID
- Added a guard to skip
Workflow.objects.getwhenworkflow_idisTEST_NOTIFICATION_ID, preventing the guaranteed-failing test-notification lookup.
- Added a guard to skip
Or push these changes by commenting:
@cursor push 4ea2161e1d
Preview (4ea2161e1d)
diff --git a/src/sentry/notifications/notification_action/types.py b/src/sentry/notifications/notification_action/types.py
--- a/src/sentry/notifications/notification_action/types.py
+++ b/src/sentry/notifications/notification_action/types.py
@@ -202,7 +202,7 @@
rule_id = None
label = None
- if workflow_id is not None:
+ if workflow_id is not None and workflow_id != TEST_NOTIFICATION_ID:
try:
workflow = Workflow.objects.get(id=workflow_id)
label = workflow.nameThis Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.
Reviewed by Cursor Bugbot for commit b859389. Configure here.
| except Workflow.DoesNotExist: | ||
| # If the workflow no longer exists, bail and use detector name | ||
| # as a fallback. | ||
| pass |
There was a problem hiding this comment.
Unnecessary DB query for test notification workflow ID
Low Severity
When workflow_id equals TEST_NOTIFICATION_ID (-1), the new code at lines 205–212 queries Workflow.objects.get(id=-1) before the test-notification check at line 220. This query will always raise Workflow.DoesNotExist for the sentinel value -1, resulting in a wasted database round-trip on every test notification. Previously, label was set directly to detector.name without any DB query. The guard for TEST_NOTIFICATION_ID needs to happen before the Workflow lookup.
Reviewed by Cursor Bugbot for commit b859389. Configure here.
| if workflow_id is not None: | ||
| try: | ||
| workflow = Workflow.objects.get(id=workflow_id) | ||
| label = workflow.name | ||
| except Workflow.DoesNotExist: | ||
| # If the workflow no longer exists, bail and use detector name | ||
| # as a fallback. | ||
| pass | ||
|
|
||
| if label is None: | ||
| label = detector.name |
There was a problem hiding this comment.
Bug: The new logic setting the alert label to workflow.name is immediately overwritten by existing code that uses the legacy rule's label for migrated alerts.
Severity: HIGH
Suggested Fix
Refactor the logic to ensure the workflow.name is prioritized. The code block that fetches and applies the legacy rule label from AlertRuleWorkflow should only execute if the label has not already been set by the new workflow logic. This will ensure the new workflow name is used when available, as intended.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: src/sentry/notifications/notification_action/types.py#L204-L215
Potential issue: The new code sets the alert `label` to the `workflow.name` when a
workflow is available. However, for migrated alerts, a subsequent block of existing code
checks for an `AlertRuleWorkflow` record. If this record is found, it overwrites the
`label` with the label from the legacy `Rule`. This negates the intended change for the
primary use case of migrated alerts, causing the old rule label to be displayed instead
of the new workflow name. The issue is masked by insufficient test coverage.
Did we get this right? 👍 / 👎 to inform future reviews.
There was a problem hiding this comment.
That should be dead code at this point. We shouldn't have a case where that ID is None at this current phase of the deployment.
Backend Test FailuresFailures on
|



Currently, we display a mixture of Detector name and alert rule link in issue alert footers. This is confusing from a user perspective, so this PR attempts to use the workflow name when available.