Software development is the process of designing and creating computer software. It can be done by different methods, but typically it involves programming a solution or building it from other available components. The complexity of this process depends on the size and type of application being developed. There are many trends in software develo...
Debugging Sidekiq Workers Using pry-remote on Rails Applications
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.
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.
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.
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.
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 sidek...
Ruby is a boon to software developers. Its design simplifies the process of creating a program letting its developers spend more time on the algorithm and functionality rather than the code itself. I have been using Ruby for years now and in this article, I’ve decided to share some of Ruby’s most interesting yet not widely known features so that...
Ruby on Rails is a popular choice for development of web applications due to it’s simplicity and prototyping speed. Rails has a very complex and all inclusive toolkit out of the box which fulfills most requirements arising during regular web application development cycles. However, when requirement becomes more specific, even Rails’ enormous inb...