Defect #44375
open
Concurrency problem in project deletion / project marking for deletion
Description
The problem we noticed was:
- a user selects some projects to be bulk deleted and submits the request
- other projects than the selected projects get marked as STATUS_SCHEDULED_FOR_DELETION
- the correct originally select projects are deleted
Our analysis showed that between selecting the projects in the ProjectsController#bulk_delete and updating the projects with the STATUS_SCHEDULED_FOR_DELETION in DestroyProjectJob.schedule another previous DestroyProjectJob might change the Project tree, which then leads to project.self_and_descendants in DestroyProjectJob.schedule to select the wrong projects.
Files
Updated by Felix Schäfer 25 days ago
- File 44375-atomic_mark_project_scheduled_for_deletion.patch 44375-atomic_mark_project_scheduled_for_deletion.patch added
See the attached patch. The patch is by Jens Krämer.
This changes the "mark project as scheduled for deletion" operation to be inside a transaction and to not use cached lft and rgt values and makes it essentially atomic. This ensures no other operation can change the project tree while the "mark project as scheduled for deletion" operation is executed.
Updated by Go MAEDA about 24 hours ago
- Status changed from New to Resolved
- Assignee set to Go MAEDA
- Resolution set to Fixed
Committed the patch in r25114. Thank you for the contribution.