Sidekiq is a fantastic solution for background processing in Ruby on Rails web applications. It allows you to run Rails code on a separate thread with really fast execution times. I have described some features of sidekiq in my article on Essential Ruby Gems For Web Application Development. In this article I will show you how you can debug sidekiq workers using pry-remote.

I have used the pry debugging tool ever since I was new to ruby and it has become an important part of my ruby development cycle. The problem with using pry in sidekiq workers is that, it doesn’t work. Since it runs on a separate thread, there is no way for you to access the break-point created by the binding.pry method call. After some research, I found the perfect solution to this problem. The solution is called pry-remote.

An Introduction to Pry Remote pry-remote is a Ruby gem that will help you create a break-point in a running application and access the break-point remotely using DRb (Distributed Ruby). Since we are unable to access the sidekiq worker thread directly, we will use pry-remote to initiate a break-point and then access the break-point by running the pry-remote cli.

Including the Pry Remote Gem Add the following line to your Gemfile and bundle the gems.

gem 'pry-remote'

Creating A Break Point in A Sidekiq Worker Open the sidekiq worker file from app/workers directory and add the following line to the file where you need to create a break-point.

binding.remote_pry

Now run the sidekiq worker. If the previous steps were executed correctly, you’ll see a message in your sidekiq log file stating that the execution of the worker has been halted and the is waiting for a client on a DRb address.

 [pry-remote] Waiting for client on drb://localhost:9876

Accessing the Break-Point Remotely Now that the break-point has been created, we can access it using the pry-remote command-line utility. Run the following in a terminal window to attach a pry REPL interface to the DRb process.

pry-remote

You should now have the access to the binding where the sidekiq thread was halted.

Developing sidekiq workers can be very difficult as there is no output value received after the execution of the worker. Using the above technique, you’ll easily be able to develop and debug sidekiq workers with the help of Pry REPL.

Stay tuned for more articles on Ruby and Rails development.