fix(workflows): Handle duplicated AlertRuleWorkflow entries for a Workflow more gracefully

[kcons]

We've got a few fixes for this situation in the works, but if we can avoid crashing in the meantime that seems ideal.

Part of ISWF-2470.

[linear-code]

ISWF-2470 AlertRuleWorkflow.MultipleObjectsReturned: get() returned more than one AlertRuleWorkflow -- it returned 2!

[sentry]

Bug: The call to AlertRuleWorkflow.objects.get() does not handle the MultipleObjectsReturned exception, which can occur if duplicate entries exist for a project, leading to a crash.
_{Severity: HIGH}

Suggested Fix

Modify the except block to catch both AlertRuleWorkflow.DoesNotExist and AlertRuleWorkflow.MultipleObjectsReturned exceptions. This pattern is common elsewhere in the codebase for handling .get() calls.

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/rules/history/backends/postgres.py#L67-L69

Potential issue: The `get_rule_workflow` function calls
`AlertRuleWorkflow.objects.get()` to retrieve a workflow. While the query is filtered by
`project_id`, it is still possible for multiple `AlertRuleWorkflow` entries to exist for
different rules within the same project. The code only handles the `DoesNotExist`
exception. If the query returns multiple objects, it will raise an unhandled
`MultipleObjectsReturned` exception, causing a crash in the
`ProjectRuleStatsIndexEndpoint` and `ProjectRuleGroupHistoryIndexEndpoint` API handlers.

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

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 926e629. Configure here.}

[cursor]

MultipleObjectsReturned not caught despite graceful-handling intent

Medium Severity

The qs.get() call can still raise MultipleObjectsReturned if more than one AlertRuleWorkflow matches after filtering — for example, if two distinct rules in the same project both point to the same workflow. The try/except only catches AlertRuleWorkflow.DoesNotExist, so a MultipleObjectsReturned exception would propagate as an unhandled 500 error. Since the PR's stated goal is to "avoid crashing," catching (or otherwise handling) MultipleObjectsReturned — e.g., by using qs.first() or adding it to the except clause — would make the fix more robust.

 

^{Reviewed by Cursor Bugbot for commit 926e629. Configure here.}

[saponifi3d]

it's true, but shouldn't convention avoid this and we'd want to be notified about this as a different error?

[kcons]

yep.

[kcons]

The bots are right, this doesn't fully prevent, but we're only trying to avoid the known duplication issue with one item per project.