mirror of
https://github.com/go-gitea/gitea.git
synced 2026-07-28 01:05:20 +02:00
d141dc729c
Backport #38534 by @luuuc Fixes #38494 `DeleteRepositoryDirectly` left rows behind in seven registered tables carrying a repo-scoped key: `action_variable`, `action_run_attempt`, `action_tasks_version`, `renamed_branch`, `commit_status_summary`, `commit_status_index` and `repo_transfer`. Repository IDs are `pk autoincr` and never reissued, so the orphaned rows were unreachable, but they accumulated forever (unbounded table growth, referential inconsistency; not a security issue, see the issue discussion). This adds all seven to the `deleteBeans` cascade, each placed next to its sibling bean (`CommitStatus`/`CommitStatusIndex`/`CommitStatusSummary`, `Branch`/`RenamedBranch`, `Secret`/`ActionVariable`, `ActionRun`/`ActionRunAttempt`). `repo_transfer` goes through the same cascade rather than `DeleteRepositoryTransfer` so teardown stays one mechanism; the existing reaper remains for the transfer flows. The test inserts one row per previously-orphaned table (the fixture files ask test cases to prepare their own data), deletes the repository, and asserts each table is purged. Without the fix it fails on all seven tables. As discussed in the issue, this is the first of the two suggested steps; the reflection-driven enforcement sweep over registered repo-keyed models (with an explicit exemption list, e.g. head-repo PRs) can follow in a separate PR. PS: this was found while benchmarking [Sense](https://github.com/luuuc/sense) against the gitea codebase (the cross-reference method is described in the issue). Signed-off-by: wxiaoguang <wxiaoguang@gmail.com> Signed-off-by: Luc <luuuc@users.noreply.github.com> Co-authored-by: Luc <luuuc@users.noreply.github.com> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>