## Problem `project.destroy!` and `group.destroy!` delete all child records in a single transaction via `ON DELETE CASCADE`. For large projects, this transaction runs for 10+ minutes. It holds locks, causes table bloat, and increases replication lag. ## Approach Delete the heaviest child tables in small, committed batches **before** calling `destroy!`. By the time the final `DELETE` runs, there is little or nothing left to cascade. This follows the [strict referential hard-deletion design](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/20016), scoped to projects and groups. We skip the organization-specific parts: state machine transitions, write-blocking, FK migrations to `RESTRICT`, and retry loops. What we skip and why: - **No FK migrations.** We leave `CASCADE` FKs in place. They clean up anything the pre-drain missed. - **No `RESTRICT` handling.** Since FKs stay `CASCADE`, the parent `DELETE` never raises `InvalidForeignKey`. - **No write-blocking.** Projects already use `pending_delete` to stop new activity. - **No abort transitions.** The worker re-enqueues itself if it runs out of budget. ## Plan 1. **Batched pre-drain helper** (generic, reusable). Discovers `CASCADE` FKs, orders them leaves-first, and deletes in committed batches with a per-run budget. 2. **Integrate into `Projects::DestroyService`.** Pre-drain heavy tables, then call `project.destroy!`. Re-enqueue if the budget runs out. 3. **Integrate into `Groups::DestroyService`.** Same pattern for group children. 4. **(Optional) Tune drain order.** Profile which tables cause the longest cascades and drain those first. ## References - Design document MR: https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/20016 - Original work item: https://gitlab.com/gitlab-org/gitlab/-/issues/601838 - Parent epic: https://gitlab.com/groups/gitlab-org/-/epics/21433