### Remove sidekiq jobs for given parameters (destructive)
```ruby
# for jobs like this:
# RepositoryImportWorker.new.perform_async(100)
id_list=[100]
queue=Sidekiq::Queue.new('repository_import')
queue.eachdo|job|
job.deleteifid_list.include?(job.args[0])
end
```
### Remove specific job ID (destructive)
```ruby
queue=Sidekiq::Queue.new('repository_import')
queue.eachdo|job|
job.deleteifjob.jid=='my-job-id'
end
```
## Canceling running jobs (destructive)
> Introduced in GitLab 12.3.
This is highly risky operation and use it as last resort.
Doing that might result in data corruption, as the job
is interrupted mid-execution and it is not guaranteed
that proper rollback of transactions is implemented.
```ruby
Gitlab::SidekiqMonitor.cancel_job('job-id')
```
> This requires the Sidekiq to be run with `SIDEKIQ_MONITOR_WORKER=1`
> environment variable.
To perform of the interrupt we use `Thread.raise` which
has number of drawbacks, as mentioned in [Why Ruby’s Timeout is dangerous (and Thread.raise is terrifying)](https://jvns.ca/blog/2015/11/27/why-rubys-timeout-is-dangerous-and-thread-dot-raise-is-terrifying/):
> This is where the implications get interesting, and terrifying. This means that an exception can get raised:
>
> * during a network request (ok, as long as the surrounding code is prepared to catch Timeout::Error)
> * during the cleanup for the network request
> * during a rescue block
> * while creating an object to save to the database afterwards
> * in any of your code, regardless of whether it could have possibly raised an exception before
>
> Nobody writes code to defend against an exception being raised on literally any line. That’s not even possible. So Thread.raise is basically like a sneak attack on your code that could result in almost anything. It would probably be okay if it were pure-functional code that did not modify any state. But this is Ruby, so that’s unlikely :)