From 17fac55f9ff9df7091290ad7fbc88fdb6cb2a7ee Mon Sep 17 00:00:00 2001 From: Dan Fuller Date: Wed, 19 Nov 2025 17:04:02 -0800 Subject: [PATCH] chore(migrations): Fix up failed deletes Deletes were silently failing if `historical_silo_assignments` wasn't updated. We prevent this from happening in https://github.com/getsentry/sentry/pull/103702/, and this cleans up the tables that should have already been removed fix lockfile --- migrations_lockfile.txt | 10 ++--- .../0007_cleanup_failed_safe_deletes.py | 36 ++++++++++++++++ .../1007_cleanup_failed_safe_deletes.py | 41 +++++++++++++++++++ .../0004_cleanup_failed_safe_deletes.py | 41 +++++++++++++++++++ .../0049_cleanup_failed_safe_deletes.py | 36 ++++++++++++++++ .../0102_cleanup_failed_safe_deletes.py | 36 ++++++++++++++++ 6 files changed, 195 insertions(+), 5 deletions(-) create mode 100644 src/sentry/feedback/migrations/0007_cleanup_failed_safe_deletes.py create mode 100644 src/sentry/migrations/1007_cleanup_failed_safe_deletes.py create mode 100644 src/sentry/releases/migrations/0004_cleanup_failed_safe_deletes.py create mode 100644 src/sentry/uptime/migrations/0049_cleanup_failed_safe_deletes.py create mode 100644 src/sentry/workflow_engine/migrations/0102_cleanup_failed_safe_deletes.py diff --git a/migrations_lockfile.txt b/migrations_lockfile.txt index 7e5efc99689f99..a1706437ad759a 100644 --- a/migrations_lockfile.txt +++ b/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 diff --git a/src/sentry/feedback/migrations/0007_cleanup_failed_safe_deletes.py b/src/sentry/feedback/migrations/0007_cleanup_failed_safe_deletes.py new file mode 100644 index 00000000000000..9f30b09c82e876 --- /dev/null +++ b/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"]}, + ), + ] diff --git a/src/sentry/migrations/1007_cleanup_failed_safe_deletes.py b/src/sentry/migrations/1007_cleanup_failed_safe_deletes.py new file mode 100644 index 00000000000000..a8c1fd8a899a92 --- /dev/null +++ b/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"]}, + ), + ] diff --git a/src/sentry/releases/migrations/0004_cleanup_failed_safe_deletes.py b/src/sentry/releases/migrations/0004_cleanup_failed_safe_deletes.py new file mode 100644 index 00000000000000..846bfa1c01f5cc --- /dev/null +++ b/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"]}, + ), + ] diff --git a/src/sentry/uptime/migrations/0049_cleanup_failed_safe_deletes.py b/src/sentry/uptime/migrations/0049_cleanup_failed_safe_deletes.py new file mode 100644 index 00000000000000..754d86151aecd0 --- /dev/null +++ b/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"]}, + ), + ] diff --git a/src/sentry/workflow_engine/migrations/0102_cleanup_failed_safe_deletes.py b/src/sentry/workflow_engine/migrations/0102_cleanup_failed_safe_deletes.py new file mode 100644 index 00000000000000..58ba3939373d44 --- /dev/null +++ b/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"]}, + ), + ]