How I Rescued a Stuck Sidekiq Queue by Reassigning Jobs

Mar 25, 2025

How I Rescued a Stuck Sidekiq Queue by Reassigning Jobs

Introduction

While working with background processing in Ruby on Rails, Sidekiq is often the go-to tool for handling jobs asynchronously. But what happens when one of your queues becomes jammed with jobs that just won't get processed? That was exactly the situation I faced recently: the default queue was clogged, and I needed to move specific jobs to a different queue without losing any data or functionality.

In this post, I’ll share the quick Ruby script I used to rescue my jobs, explain how it works, and give tips on how you can safely manipulate Sidekiq queues when things go sideways.

The Problem

My Sidekiq default queue was full of jobs, and due to prioritization rules, some of them weren’t being picked up in time. I noticed that many of the stuck jobs were instances of the PostOfficeWorker, and I wanted to reroute them to a less busy queue called services.

The Solution: Reassigning Jobs

Here’s the Ruby script I used directly in the Rails console to achieve this:

queue = Sidekiq::Queue.new("default")queue.each do |job|  wrapper_args = job.args.first  if wrapper_args["job_class"] == "PostOfficeWorker"    worker_class = wrapper_args["job_class"].constantize    puts worker_class    original_args = wrapper_args["arguments"]    puts original_args    worker_class.set(queue: 'services').perform_later(*original_args)    job.delete  endend

What This Script Does:

  1. Accesses the default queue: Sidekiq::Queue.new("default")
  2. Iterates through all jobs in that queue.
  3. Identifies jobs with job_class set to PostOfficeWorker.
  4. Extracts the original arguments passed to the job.
  5. Re-enqueues the job using .set(queue: 'services').perform_later(...) to the services queue.
  6. Deletes the original job from the default queue to avoid duplication.

Important Notes

  • Perform Safely: Always double-check that you're targeting the correct jobs and arguments. Consider doing a dry run without job.delete first.
  • Monitor the Result: Use Sidekiq Web UI or log monitoring to ensure that jobs are successfully moved and executed.
  • Use Namespaces: If you’re running multiple environments or workers, ensure you’re accessing the correct Redis namespace.
  • Backups: In critical systems, consider exporting job payloads before deleting anything.

Conclusion

Sidekiq is powerful, but like any queue system, it’s only as resilient as your job handling strategy. When queues become unbalanced, scripts like the one above can help redistribute the load and keep your application responsive.

If you ever face a stuck queue scenario, don’t panic. With a little Ruby and an understanding of how jobs are structured internally, you can take control and reroute jobs efficiently.