chore(migrations): Fix up failed deletes

Deletes were silently failing if `historical_silo_assignments` wasn't updated. We prevent this from happening in #103702, and this cleans up the tables that should have already been removed

fix lockfile

Author: wedamija

migrations_lockfile.txt

@@ -9,7 +9,7 @@ discover: 0003_discover_json_field
 
 explore: 0006_add_changed_reason_field_explore
 
-feedback: 0006_safe_del_feedback_model
+feedback: 0007_cleanup_failed_safe_deletes
 
 flags: 0001_squashed_0004_add_flag_audit_log_provider_column
 
@@ -27,16 +27,16 @@ preprod: 0018_add_preprod_artifact_app_icon_id_field
 
 prevent: 0002_alter_integration_id_not_null
 
-releases: 0003_real_delete_dual_written_commit_tables
+releases: 0004_cleanup_failed_safe_deletes
 
 replays: 0006_add_bulk_delete_job
 
-sentry: 1006_drop_legacy_incidentseen_incidentsubscription
+sentry: 1007_cleanup_failed_safe_deletes
 
 social_auth: 0003_social_auth_json_field
 
 tempest: 0003_use_encrypted_char_field
 
-uptime: 0048_delete_uptime_status_columns
+uptime: 0049_cleanup_failed_safe_deletes
 
-workflow_engine: 0101_remove_is_single_written_field
+workflow_engine: 0102_cleanup_failed_safe_deletes

src/sentry/feedback/migrations/0007_cleanup_failed_safe_deletes.py

@@ -0,0 +1,36 @@
+# Generated by Django 5.2.8 on 2025-11-19 00:38
+
+from django.db import migrations
+
+from sentry.new_migrations.migrations import CheckedMigration
+from sentry.new_migrations.monkey.special import SafeRunSQL
+
+
+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 = [
+        ("feedback", "0006_safe_del_feedback_model"),
+    ]
+
+    operations = [
+        # Clean up table that may not have been deleted due to missing
+        # historical_silo_assignments entry before the fix
+        SafeRunSQL(
+            sql="DROP TABLE IF EXISTS feedback_feedback CASCADE;",
+            reverse_sql=migrations.RunSQL.noop,
+            hints={"tables": ["feedback_feedback"]},
+        ),
+    ]

src/sentry/migrations/1007_cleanup_failed_safe_deletes.py

@@ -0,0 +1,41 @@
+# Generated by Django 5.2.8 on 2025-11-19 00:37
+
+from django.db import migrations
+
+from sentry.new_migrations.migrations import CheckedMigration
+from sentry.new_migrations.monkey.special import SafeRunSQL
+
+
+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", "1006_drop_legacy_incidentseen_incidentsubscription"),
+    ]
+
+    operations = [
+        # Clean up tables that may not have been deleted due to missing
+        # historical_silo_assignments entries before the fix
+        SafeRunSQL(
+            sql="DROP TABLE IF EXISTS sentry_datasecrecywaiver CASCADE;",
+            reverse_sql=migrations.RunSQL.noop,
+            hints={"tables": ["sentry_datasecrecywaiver"]},
+        ),
+        SafeRunSQL(
+            sql="DROP TABLE IF EXISTS sentry_dashboardwidgetsnapshot CASCADE;",
+            reverse_sql=migrations.RunSQL.noop,
+            hints={"tables": ["sentry_dashboardwidgetsnapshot"]},
+        ),
+    ]

src/sentry/releases/migrations/0004_cleanup_failed_safe_deletes.py

@@ -0,0 +1,41 @@
+# Generated by Django 5.2.8 on 2025-11-19 00:38
+
+from django.db import migrations
+
+from sentry.new_migrations.migrations import CheckedMigration
+from sentry.new_migrations.monkey.special import SafeRunSQL
+
+
+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 = [
+        ("releases", "0003_real_delete_dual_written_commit_tables"),
+    ]
+
+    operations = [
+        # Clean up tables that may not have been deleted due to missing
+        # historical_silo_assignments entries before the fix
+        SafeRunSQL(
+            sql="DROP TABLE IF EXISTS releases_commit CASCADE;",
+            reverse_sql=migrations.RunSQL.noop,
+            hints={"tables": ["releases_commit"]},
+        ),
+        SafeRunSQL(
+            sql="DROP TABLE IF EXISTS releases_commitfilechange CASCADE;",
+            reverse_sql=migrations.RunSQL.noop,
+            hints={"tables": ["releases_commitfilechange"]},
+        ),
+    ]

src/sentry/uptime/migrations/0049_cleanup_failed_safe_deletes.py

@@ -0,0 +1,36 @@
+# Generated by Django 5.2.8 on 2025-11-19 00:38
+
+from django.db import migrations
+
+from sentry.new_migrations.migrations import CheckedMigration
+from sentry.new_migrations.monkey.special import SafeRunSQL
+
+
+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 = [
+        ("uptime", "0048_delete_uptime_status_columns"),
+    ]
+
+    operations = [
+        # Clean up table that may not have been deleted due to missing
+        # historical_silo_assignments entry before the fix
+        SafeRunSQL(
+            sql="DROP TABLE IF EXISTS uptime_projectuptimesubscription CASCADE;",
+            reverse_sql=migrations.RunSQL.noop,
+            hints={"tables": ["uptime_projectuptimesubscription"]},
+        ),
+    ]

src/sentry/workflow_engine/migrations/0102_cleanup_failed_safe_deletes.py

@@ -0,0 +1,36 @@
+# Generated by Django 5.2.8 on 2025-11-19 00:38
+
+from django.db import migrations
+
+from sentry.new_migrations.migrations import CheckedMigration
+from sentry.new_migrations.monkey.special import SafeRunSQL
+
+
+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 = [
+        ("workflow_engine", "0101_remove_is_single_written_field"),
+    ]
+
+    operations = [
+        # Clean up table that may not have been deleted due to missing
+        # historical_silo_assignments entry before the fix
+        SafeRunSQL(
+            sql="DROP TABLE IF EXISTS workflow_engine_actiongroupstatus CASCADE;",
+            reverse_sql=migrations.RunSQL.noop,
+            hints={"tables": ["workflow_engine_actiongroupstatus"]},
+        ),
+    ]