Today I Learned

Debugging with backtrace

From time to time, especially when I’m dealing with really complex apps, I struggle to analyze what is happening between a request hitting the puma server and stopping in binding.pry. The solution to that problem is to change the debugging approach from the outside in to the inside out. To do so, we can use one of the ruby Kernel methods called caller. It is going to show us a stack trace similar to the one you can see on the every rails error page.

[1] pry(#<ProductBuyer>)> caller.select { |x| x.include?(Rails.root.to_s) }
=> [
"/root/projects/ruby/secret_project_name/app/services/product_buyer.rb:34:in `block in perform'",
"/root/projects/ruby/secret_project_name/app/services/product_buyer.rb:33:in `perform'",
"/root/projects/ruby/secret_project_name/app/services/product_buyer.rb:13:in `call'",
"/root/projects/ruby/secret_project_name/app/controllers/products/purchase_controller.rb:8:in `create'",
"/root/projects/ruby/secret_project_name/app/controllers/application_controller.rb:98:in `block in set_locale'",
"/root/projects/ruby/secret_project_name/app/controllers/application_controller.rb:97:in `set_locale'",
"/root/projects/ruby/secret_project_name/config/initializers/locale_middleware.rb:17:in `call'",
"/root/projects/ruby/secret_project_name/lib/cors_middleware.rb:12:in `call'"
]

select { |x| x.include?(Rails.root.to_s) } was added to get rid of all gems related entries