chore(group_history): Safe removal of prev_history

migrations_lockfile.txt

@@ -31,7 +31,7 @@ releases: 0002_delete_dual_written_commit_tables
 
 replays: 0006_add_bulk_delete_job
 
-sentry: 1001_prevent_grouphistory_infinte_recursion
+sentry: 1002_group_history_prev_history_remove_db_constraint_and_safe_removal
 
 social_auth: 0003_social_auth_json_field
 

src/sentry/migrations/1002_group_history_prev_history_remove_db_constraint_and_safe_removal.py

@@ -0,0 +1,49 @@
+# Generated by Django 5.2.1 on 2025-11-04 13:30
+
+import django.db.models.deletion
+from django.db import migrations
+
+from sentry.db.models.fields.foreignkey import FlexibleForeignKey
+from sentry.new_migrations.migrations import CheckedMigration
+from sentry.new_migrations.monkey.fields import SafeRemoveField
+from sentry.new_migrations.monkey.state import DeletionAction
+
+
+class Migration(CheckedMigration):
+    # This flag is used to mark that a migration shouldn't be automatically run in production.
+    # This should only be used for operations where it's safe to run the migration after your
+    # code has deployed. So this should not be used for most operations that alter the schema
+    # of a table.
+    # Here are some things that make sense to mark as post deployment:
+    # - Large data migrations. Typically we want these to be run manually so that they can be
+    #   monitored and not block the deploy for a long period of time while they run.
+    # - Adding indexes to large tables. Since this can take a long time, we'd generally prefer to
+    #   run this outside deployments so that we don't block them. Note that while adding an index
+    #   is a schema change, it's completely safe to run the operation after the code has deployed.
+    # Once deployed, run these manually via: https://develop.sentry.dev/database-migrations/#migration-deployment
+
+    is_post_deployment = False
+
+    dependencies = [
+        ("sentry", "1001_prevent_grouphistory_infinte_recursion"),
+    ]
+
+    operations = [
+        migrations.AlterField(
+            model_name="grouphistory",
+            name="prev_history",
+            field=FlexibleForeignKey(
+                # We want to remove the database-level foreign key constraint
+                db_constraint=False,
+                null=True,
+                on_delete=django.db.models.deletion.SET_NULL,
+                to="sentry.grouphistory",
+            ),
+        ),
+        # This marks the field as pending deletion
+        SafeRemoveField(
+            model_name="grouphistory",
+            name="prev_history",
+            deletion_action=DeletionAction.MOVE_TO_PENDING,
+        ),
+    ]

src/sentry/models/grouphistory.py

@@ -213,8 +213,18 @@ class GroupHistory(Model):
         ),
     )
     prev_history = FlexibleForeignKey(
-        "sentry.GroupHistory", null=True, on_delete=models.SET_NULL
-    )  # This field has no immediate use, but might be useful.
+        "sentry.GroupHistory",
+        null=True,
+        on_delete=models.SET_NULL,
+        # By default, Django creates a database-level foreign key constraint when you define a ForeignKey field.
+        # This constraint enforces referential integrity at the database level, preventing you from:
+        # * Deleting a referenced record without handling the reference
+        # * Creating a reference to a non-existent record
+        # When you set db_constraint=False, Django skips creating this database constraint.
+        # The field still works as a ForeignKey in Python/Django (you can traverse relationships,
+        # use .select_related(), etc.), but the database won't enforce the relationship.
+        db_constraint=False,
+    )
     prev_history_date = models.DateTimeField(
         null=True
     )  # This field is used to simplify query calculations.