ref(workflow_engine): Convert OwnerModel.owner_team FK to BigInt

[beezz]

The OwnerModel abstract base class defines owner_team as a FlexibleForeignKey
to sentry.Team. This FK creates a database-level constraint that assumes both
tables reside in the same database, which is not desirable in our sharded
environment where tables may be placed on different database instances.

This converts owner_team to a BoundedBigIntegerField (owner_team_id) for
the two concrete models that inherit from OwnerModel: Detector and Workflow
(both in workflow_engine app). The Rule model defines its own owner_team FK
separately and is not in scope.

The migration uses SeparateDatabaseAndState to drop the FK constraint at the
database level while updating Django state to use a plain integer field. Also adds
nullification of owner_team_id on Detector and Workflow in the team deletion
handler, matching the existing pattern for Rule and Monitor.

[cursor]

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

Autofix Details

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Migration removes non-existent constraint from Workflow state
  • Removed the Workflow RemoveConstraint and corresponding AddConstraint state operations in migration 0110 because that constraint never existed in workflow migration state or model metadata.

Or push these changes by commenting:

@cursor push 8372276a40

Preview (8372276a40)

diff --git a/src/sentry/workflow_engine/migrations/0110_owner_team_break_fk.py b/src/sentry/workflow_engine/migrations/0110_owner_team_break_fk.py
--- a/src/sentry/workflow_engine/migrations/0110_owner_team_break_fk.py
+++ b/src/sentry/workflow_engine/migrations/0110_owner_team_break_fk.py
@@ -72,10 +72,6 @@
                 ),
             ],
             state_operations=[
-                migrations.RemoveConstraint(
-                    model_name="workflow",
-                    name="workflow_engine_workflow_owner_constraints",
-                ),
                 migrations.RemoveField(
                     model_name="workflow",
                     name="owner_team",
@@ -87,17 +83,6 @@
                         blank=True, db_index=True, null=True
                     ),
                 ),
-                migrations.AddConstraint(
-                    model_name="workflow",
-                    constraint=models.CheckConstraint(
-                        condition=(
-                            models.Q(owner_user_id__isnull=True, owner_team_id__isnull=False)
-                            | models.Q(owner_user_id__isnull=False, owner_team_id__isnull=True)
-                            | models.Q(owner_user_id__isnull=True, owner_team_id__isnull=True)
-                        ),
-                        name="workflow_engine_workflow_owner_constraints",
-                    ),
-                ),
             ],
         ),
     ]

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

[github-actions]

This PR has a migration; here is the generated SQL for src/sentry/workflow_engine/migrations/0110_owner_team_break_fk.py

for 0110_owner_team_break_fk in workflow_engine

--
-- Custom state/database change combination
--
SET CONSTRAINTS "workflow_engine_dete_owner_team_id_177670f3_fk_sentry_te" IMMEDIATE; ALTER TABLE "workflow_engine_detector" DROP CONSTRAINT "workflow_engine_dete_owner_team_id_177670f3_fk_sentry_te";
--
-- Custom state/database change combination
--
SET CONSTRAINTS "workflow_engine_work_owner_team_id_c401e7b8_fk_sentry_te" IMMEDIATE; ALTER TABLE "workflow_engine_workflow" DROP CONSTRAINT "workflow_engine_work_owner_team_id_c401e7b8_fk_sentry_te";

[github-actions]

Backend Test Failures

Failures on 0e25ffd in this run:

tests/sentry/api/serializers/test_rule.py::WorkflowRuleSerializerTest::test_fetch_workflow_owner__team — log

tests/sentry/api/serializers/test_rule.py:282: in test_fetch_workflow_owner__team
    workflow = self.create_workflow(owner_team=team)
src/sentry/testutils/fixtures.py:690: in create_workflow
    return Factories.create_workflow(*args, **kwargs)
/opt/hostedtoolcache/Python/3.13.1/x64/lib/python3.13/contextlib.py:85: in inner
    return func(*args, **kwds)
src/sentry/testutils/factories.py:2269: in create_workflow
    return Workflow.objects.create(
src/sentry/silo/base.py:158: in override
    return original_method(*args, **kwargs)
.venv/lib/python3.13/site-packages/django/db/models/manager.py:87: in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
src/sentry/silo/base.py:158: in override
    return original_method(*args, **kwargs)
.venv/lib/python3.13/site-packages/django/db/models/query.py:663: in create
    obj = self.model(**kwargs)
.venv/lib/python3.13/site-packages/django/db/models/base.py:569: in __init__
    raise TypeError(
E   TypeError: Workflow() got unexpected keyword arguments: 'owner_team'

[markstory]

Looks good to me. The constraint drops will leave indexes behind so query performance should not be impacted.

[markstory]

It looks like most team deletions are done through scheduled deletions so we shouldn't have dangling references in detectors/workflows.

[beezz]

Agreed that scheduled deletions handle the cascading cleanup when the FK exists. However, this PR converts owner_team from a ForeignKey (with on_delete=SET_NULL) to a plain BoundedBigIntegerField, so the DB will no longer automatically null these out on team deletion. The manual cleanup here ensures we don't end up with dangling team IDs pointing to deleted teams.

— Claude Code

[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.}

[cursor]

Custom managers skip nullifying deletion-state objects' team references

Low Severity

Detector.objects and Workflow.objects use custom managers (DetectorManager, WorkflowManager) that exclude rows with PENDING_DELETION or DELETION_IN_PROGRESS status. These nullification queries will silently skip any detectors or workflows in those states, leaving dangling owner_team_id values. Previously, the database-level ON DELETE SET_NULL from the FK constraint would have nullified all rows regardless of Django manager filtering. This is unlikely to cause real problems since those objects are mid-deletion, but it's a subtle behavioral change from the FK-based cascade.