feat(deletion): Add partition support to BulkDeleteQuery and cleanup command

[dashed]

Summary

• Add partition parameter to BulkDeleteQuery to split deletion work across multiple runs using modulo-based row bucketing
• Add --partition-bucket, --partition-total, and --partition-key flags to the sentry cleanup CLI command
• Fully backward compatible: behavior is unchanged when partition flags are not provided

Problem

The daily sentry cleanup CronJob for SpikeProjections and Spike models runs a tight DELETE loop via BulkDeleteQuery._continuous_query(), creating a burst of dead tuples on db-usage-1. This triggers a massive autovacuum that causes WAL replication delay, forcing db-usage-repl to fall back to GSCP recovery.

Since valid_date values are always at midnight UTC, simply running the CronJob more frequently doesn't help — all eligible rows become deletable at the same instant. We need a way to partition the rows across multiple runs.

Solution

Add id % N partitioning to BulkDeleteQuery:

sentry cleanup --model=SpikeProjections --days=90 --partition-bucket=0 --partition-total=4
sentry cleanup --model=SpikeProjections --days=90 --partition-bucket=1 --partition-total=4
sentry cleanup --model=SpikeProjections --days=90 --partition-bucket=2 --partition-total=4
sentry cleanup --model=SpikeProjections --days=90 --partition-bucket=3 --partition-total=4

Each run adds WHERE id % 4 = {bucket} to the DELETE query, handling ~25% of eligible rows. The --partition-key flag allows using a different column (defaults to id).

Using id (auto-increment) ensures uniform distribution, following the same principle as PR #18736 which switched spike projection batching from organization_id (snowflake, uneven) to subscription.id (auto-increment, uniform).

Changes

src/sentry/db/deletion.py

• Added partition: tuple[int, int, str] | None parameter to BulkDeleteQuery.__init__()
• Added partition filter to the WHERE clause in execute()
• Added partition filter to iterator() via Func(F(key), Value(total), function="MOD")

src/sentry/runner/commands/cleanup.py

• Added --partition-bucket CLI flag (integer, 0-based bucket index)
• Added --partition-total CLI flag (integer, total number of buckets)
• Added --partition-key CLI flag (default: id)
• Validation: both bucket and total must be used together, bucket must be non-negative and less than total, total must be positive
• Threaded through cleanup() → _cleanup() → run_bulk_query_deletes() → BulkDeleteQuery()

Test plan

• test_partition_restriction — verifies only rows in the matching bucket are deleted
• test_partition_with_datetime_restriction — combines partition + date filter
• test_partition_all_buckets_cover_all_rows — verifies complete coverage across all buckets
• test_iteration_with_partition — verifies iterator() respects partition filter
• test_partition_bucket_exceeds_total — validation error for bucket >= total
• test_partition_negative_bucket — validation error for negative bucket
• test_partition_zero_total — validation error for zero total
• test_partition_bucket_without_total — validation error when only bucket is set
• test_partition_total_without_bucket — validation error when only total is set

Related

• Ops PR (K8s config): https://github.com/getsentry/ops/pull/19081
• Analysis: daily mass deletion on accounts_spike_projections causes replication delay on db-usage-1

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

[ajay-sentry]

a thought here, is we could have had 2 separate params here for total_buckets and bucket_id or smth to make it a little more straightforward

[ajay-sentry]

looks good, I see partition_key isn't used on the cron but makes sense if we want to easily update later