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

class GroupDestroyWorker
  include ApplicationWorker
  include ExceptionBacktrace

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

    user = User.find(user_id)

    Groups::DestroyService.new(group, user).execute
  end
end
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			`class GroupDestroyWorker`
Add ApplicationWorker and make every worker include it 2017-11-28 11:08:30 -05:00			`include ApplicationWorker`
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
			`def perform(group_id, user_id)`
			`begin`
			`group = Group.with_deleted.find(group_id)`
			`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`