Loading
Clean up RubyGems spec files marked pending_destruction
What does this MR do and why?
When a project is deleted, a loose foreign key marks its rows in packages_rubygems_spec_files as pending_destruction (config/gitlab_loose_foreign_keys.yml, on_delete: update_column_to, target_value: 2). However, no worker was previously enqueued to remove these records or delete their artifacts from object storage.
This MR introduces Packages::Rubygems::CleanupStaleSpecFilesWorker, modeled on Packages::Npm::CleanupStaleMetadataCacheWorker and Packages::Helm::CleanupStaleMetadataCacheWorker:
- Adds
Packages::Rubygems::CleanupStaleSpecFilesWorkerincludingPackages::CleanupArtifactWorker. - Enqueues the worker from
Packages::CleanupPackageRegistryWorker#performwhenPackages::Rubygems::SpecFile.pending_destruction.exists?. - Declares the data retention policy in
db/docs/data_retention/packages_rubygems_spec_files.ymlwithenforcing: trueand removes the table fromspec/support/database/retention-policy-missing-allowlist.yml. - Adds complete unit specs and Sidekiq worker metadata.
Closes #633765
Database Query & Execution Plan
Packages::Rubygems::SpecFile.pending_destruction.any?
SELECT 1 AS one FROM "packages_rubygems_spec_files" WHERE "packages_rubygems_spec_files"."status" = 2 LIMIT 1Limit (actual time=3.614..3.615 rows=0 loops=1)
Buffers: shared read=1
-> Index Only Scan using index_packages_rubygems_spec_files_on_project_id_and_status
Index Cond: (status = 2)
Heap Fetches: 0
Buffers: shared read=1
Time: 4.163 ms (planning 0.517 ms, execution 3.646 ms, of which I/O 3.599 ms)Edited by Pavan Kumar Sadashiv