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
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
There might be some projects where the namespace was removed, but the
project wasn't. For these the projects still have a `namespace_id`
set. So this adds a post-deploy migration remove all projects that are
pending delete, and have a `namespace_id` that is non-existing.
Destroying projects can be very time consuming. So instead of destroying them in
the post-deploy, just schedule them and make Sidekiq do the hard work.
They are scheduled in batches of 5000 records. This way the number of database
requests is limited while also the amount data read to memory is limited.
Stan Hu