Skip to content

Adjourned deletion cron jobs not registered in Community Edition installations

Summary

Adjourned deletion cron jobs are not registered in GitLab Community Edition installations, causing projects and groups to remain in pending deletion state indefinitely. This affects all CE installations after the delayed deletion feature was moved from EE to CE.

Steps to reproduce

  1. Install GitLab Community Edition 18.0+
  2. Delete a project or group (which should enter "pending deletion" state)
  3. Wait past the configured deletion_adjourned_period (default 7 days)
  4. Check Rails console: Sidekiq::Cron::Job.all.select { |j| j.name.include?('adjourned') }.map(&:name)
  5. Observe that no adjourned deletion cron jobs are registered

Example Project

This affects system-level functionality and can be reproduced on any GitLab CE installation by attempting to delete a project/group and checking the cron job registration.

What is the current bug behavior?

  1. Projects and groups deleted in CE remain in "pending deletion" state forever
  2. The adjourned deletion cron workers (AdjournedProjectsDeletionCronWorker and AdjournedGroupDeletionWorker) are never scheduled
  3. Rails console shows no adjourned deletion cron jobs registered: []
  4. Manual deletion still works, but automatic cleanup after the grace period does not

What is the expected correct behavior?

  1. Projects and groups should be automatically deleted after the configured grace period (deletion_adjourned_period)
  2. Cron jobs should be registered for AdjournedProjectsDeletionCronWorker and AdjournedGroupDeletionWorker
  3. Rails console should show: ["adjourned_group_deletion", "adjourned_projects_deletion_cron"]

Relevant logs and/or screenshots

# Current state in Rails console on CE:
irb> puts "EE enabled: #{Gitlab.ee?}"
EE enabled: false

irb> Sidekiq::Cron::Job.all.select { |j| j.name.include?('adjourned') }.map(&:name)
=> []

# Workers exist but are not scheduled:
irb> defined?(AdjournedGroupDeletionWorker)
=> "constant"
irb> defined?(AdjournedProjectsDeletionCronWorker) 
=> "constant"

Output of checks

This bug affects GitLab Community Edition installations.

Results of GitLab environment info

Expand for output related to GitLab environment info 
GitLab version: 18.0+
GitLab revision: N/A
Edition: Community Edition (CE)

Possible fixes

Root cause: The cron job configuration for adjourned deletion workers is inside the Gitlab.ee block in config/initializers/1_settings.rb.

# Lines 803-808 are currently inside Gitlab.ee block:
Gitlab.ee do
  Settings.cron_jobs['adjourned_group_deletion_worker'] ||= {}
  Settings.cron_jobs['adjourned_group_deletion_worker']['cron'] ||= '0 2 * * *'
  Settings.cron_jobs['adjourned_group_deletion_worker']['job_class'] = 'AdjournedGroupDeletionWorker'
  Settings.cron_jobs['adjourned_projects_deletion_cron_worker'] ||= {}
  Settings.cron_jobs['adjourned_projects_deletion_cron_worker']['cron'] ||= '0 7 * * *'
  Settings.cron_jobs['adjourned_projects_deletion_cron_worker']['job_class'] = 'AdjournedProjectsDeletionCronWorker'

Fix: Move these 6 lines outside the Gitlab.ee block since the workers were moved to CE in MR !185875 as part of Epic &17208.

Verification:

# After fix, should show both workers:
irb> Sidekiq::Cron::Job.all.select { |j| j.name.include?('adjourned') }.map(&:name)
=> ["adjourned_group_deletion", "adjourned_projects_deletion_cron"]

Patch release information for backports

This bug affects all GitLab CE installations running 18.0+ and should be considered for backporting as it breaks a core feature (delayed deletion) for all Community Edition users.

Edited by 🤖 GitLab Bot 🤖