kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity
gitlab-org--gitlab-foss/app/workers/group_destroy_worker.rb

22 lines
450 B
Ruby
Raw Normal View History

Enable frozen string literals for app/workers/*.rb
2018-06-27 07:23:28 +00:00
# frozen_string_literal: true
Add latest changes from gitlab-org/gitlab@master
2020-02-19 18:09:10 +00:00
class GroupDestroyWorker # rubocop:disable Scalability/IdempotentWorker
Add ApplicationWorker and make every worker include it
2017-11-28 16:08:30 +00: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 19:24:58 +00: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-29 02:54:17 +00:00
Add latest changes from gitlab-org/gitlab@master
2020-01-09 12:08:03 +00:00
feature_category :subgroups
Add latest changes from gitlab-org/gitlab@master
2020-10-07 15:08:40 +00:00
tags :requires_disk_io
Add latest changes from gitlab-org/gitlab@master
2019-10-18 11:11:44 +00: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-29 02:54:17 +00: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 16:21:28 +00: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-29 02:54:17 +00: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 12:45:31 +00: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-29 02:54:17 +00:00
end
end