gitlab-org--gitlab-foss/app/workers/group_destroy_worker.rb

# frozen_string_literal: true

class GroupDestroyWorker # rubocop:disable Scalability/IdempotentWorker
  include ApplicationWorker

  sidekiq_options retry: 3
  include ExceptionBacktrace

  feature_category :subgroups
  tags :requires_disk_io, :exclude_from_kubernetes

  def perform(group_id, user_id)
    begin
      group = Group.find(group_id)
    rescue ActiveRecord::RecordNotFound
      return
    end

    user = User.find(user_id)

    Groups::DestroyService.new(group, user).execute
  end
end
Enable frozen string literals for app/workers/*.rb 2018-06-27 03:23:28 -04:00			`# frozen_string_literal: true`

Add latest changes from gitlab-org/gitlab@master 2020-02-19 13:09:10 -05:00			`class GroupDestroyWorker # rubocop:disable Scalability/IdempotentWorker`
Add ApplicationWorker and make every worker include it 2017-11-28 11:08:30 -05:00			`include ApplicationWorker`
Add latest changes from gitlab-org/gitlab@master 2021-04-30 14:10:09 -04:00
			`sidekiq_options retry: 3`
Enable 5 lines of Sidekiq backtrace lines to aid in debugging Customers often have Sidekiq jobs that failed without much context. Without Sentry, there's no way to tell where these exceptions were hit. Adding in additional lines adds a bit more Redis storage overhead. This commit adds in backtrace logging for workers that delete groups/projects and import/export projects. Closes #27626 2017-08-24 15:24:58 -04:00			`include ExceptionBacktrace`
Fix bug where destroying a namespace would not always destroy projects There is a race condition in DestroyGroupService now that projects are deleted asynchronously: 1. User attempts to delete group 2. DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project 3. DestroyGroupService destroys the Group, leaving all its projects without a namespace 4. Projects::DestroyService runs later but the can?(current_user, :remove_project) is `false` because the user no longer has permission to destroy projects with no namespace. 5. This leaves the project in pending_delete state with no namespace/group. Projects without a namespace or group also adds another problem: it's not possible to destroy the container registry tags, since container_registry_path_with_namespace is the wrong value. The fix is to destroy the group asynchronously and to run execute directly on Projects::DestroyService. Closes #17893 2016-05-28 22:54:17 -04:00
Add latest changes from gitlab-org/gitlab@master 2020-01-09 07:08:03 -05:00			`feature_category :subgroups`
Add latest changes from gitlab-org/gitlab@master 2021-05-03 05:10:02 -04:00			`tags :requires_disk_io, :exclude_from_kubernetes`
Add latest changes from gitlab-org/gitlab@master 2019-10-18 07:11:44 -04:00
Fix bug where destroying a namespace would not always destroy projects There is a race condition in DestroyGroupService now that projects are deleted asynchronously: 1. User attempts to delete group 2. DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project 3. DestroyGroupService destroys the Group, leaving all its projects without a namespace 4. Projects::DestroyService runs later but the can?(current_user, :remove_project) is `false` because the user no longer has permission to destroy projects with no namespace. 5. This leaves the project in pending_delete state with no namespace/group. Projects without a namespace or group also adds another problem: it's not possible to destroy the container registry tags, since container_registry_path_with_namespace is the wrong value. The fix is to destroy the group asynchronously and to run execute directly on Projects::DestroyService. Closes #17893 2016-05-28 22:54:17 -04:00			`def perform(group_id, user_id)`
			`begin`
Remove soft removals related code This removes all usage of soft removals except for the "pending delete" system implemented for projects. This in turn simplifies all the query plans of the models that used soft removals. Since we don't really use soft removals for anything useful there's no point in keeping it around. This _does_ mean that hard removals of issues (which only admins can do if I'm not mistaken) can influence the "iid" values, but that code is broken to begin with. More on this (and how to fix it) can be found in https://gitlab.com/gitlab-org/gitlab-ce/issues/31114. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37447 2018-01-02 11:21:28 -05:00			`group = Group.find(group_id)`
Fix bug where destroying a namespace would not always destroy projects There is a race condition in DestroyGroupService now that projects are deleted asynchronously: 1. User attempts to delete group 2. DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project 3. DestroyGroupService destroys the Group, leaving all its projects without a namespace 4. Projects::DestroyService runs later but the can?(current_user, :remove_project) is `false` because the user no longer has permission to destroy projects with no namespace. 5. This leaves the project in pending_delete state with no namespace/group. Projects without a namespace or group also adds another problem: it's not possible to destroy the container registry tags, since container_registry_path_with_namespace is the wrong value. The fix is to destroy the group asynchronously and to run execute directly on Projects::DestroyService. Closes #17893 2016-05-28 22:54:17 -04:00			`rescue ActiveRecord::RecordNotFound`
			`return`
			`end`

			`user = User.find(user_id)`

Fix inconsistent naming for services that delete things * Changed name of delete_user_service and worker to destroy * Move and change delete_group_service to Groups::DestroyService * Rename Notes::DeleteService to Notes::DestroyService 2016-08-13 08:45:31 -04:00			`Groups::DestroyService.new(group, user).execute`
Fix bug where destroying a namespace would not always destroy projects There is a race condition in DestroyGroupService now that projects are deleted asynchronously: 1. User attempts to delete group 2. DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project 3. DestroyGroupService destroys the Group, leaving all its projects without a namespace 4. Projects::DestroyService runs later but the can?(current_user, :remove_project) is `false` because the user no longer has permission to destroy projects with no namespace. 5. This leaves the project in pending_delete state with no namespace/group. Projects without a namespace or group also adds another problem: it's not possible to destroy the container registry tags, since container_registry_path_with_namespace is the wrong value. The fix is to destroy the group asynchronously and to run execute directly on Projects::DestroyService. Closes #17893 2016-05-28 22:54:17 -04:00			`end`
			`end`