Unable to immediatelly transfer project to another root namespace after removing NPM packages
Summary
After introducing the new scalable way to delete package files in MR1 and MR2, we have an issue with project.has_packages?(:npm)
check in transfer project service. If a user wants to move a project that contains npm packages, they will go to remove them before initiating the transfer. However, because instead of immediately removing the packages we now mark them as status: "pending_destruction"
, the project.has_packages?(:npm)
check will be true
.
This is confusing because UI and API will not show packages with status: "pending_destruction"
, but the customer will not be able to move the project to a different root namespace. They will still be getting "Root namespace can't be updated if project has NPM packages" error.
Customer ticket: https://gitlab.zendesk.com/agent/tickets/316559 (internal)
Steps to reproduce
- Create a project and publish an NPM package to it.
- Go to Package Registry -> delete the package.
- Go to Settings -> Advanced -> Transfer project and select a different root namespace to move this project to. => You will not be able to move the project with "Root namespace can't be updated if project has NPM packages" error.
They will be able to transfer the project only after CleanupPackageRegistryWorker
cronjob runs which happens twice a day.
What is the current bug behavior?
The customer removes NPM packages, but is still unable to transfer the project to a different root namespace. They have to wait for CleanupPackageRegistryWorker
cronjob to run which doesn't happen very often.
What is the expected correct behavior?
After removing all NPM packages the customer should be able to immediately transfer the project to a different root namespace.
Output of checks
This bug happens on GitLab.com
Possible fixes
We need to change the project.has_packages?(:npm)
check to not count packages with status: "pending_destruction"
.