Favorite Rails and JavaScript debugging tips

Rails
11

Here’s one for when you’re really stuck tracking down why a test or web request fails. I had to use this for figuring out an very hard to debug Rails 3 to Rails 4 migration bug. I’ll use RAILS_3 and RAILS_4 to distinguish between the two branches of code that I’m debugging.

  1. Be able to reproduce the passing operation on RAILS_3 and see the failure on RAILS_4.
  2. Clear out the logs on both both envs with rake log:clear
  3. Set both envs to have logging set to :debug. Be sure that you can see the SQL being logged.
  4. Run both branches, and save the log results of running both (and only the single operations) to 2 text files, which we’ll call rails_3.log and rails_4.log.
  5. Open those files up in your text editor and search and replace using this regexp to strip out the leading timestamps: ^\[.*\]. This filters out messages like this:
[DEBUG 11-18 14:06:53.463]    (5.6ms)  TRUNCATE TABLE `versions`;

Depending on how you’re doing logging, you might need a different regexp. The key is to strip out anything that causes every line to differ.
6. Then use your favorite diff tool to compare the files. I use ediff within spacemacs. Any good diff tool should work.

And then you’ll be able to see some very interesting details regarding where your positive case differs from the failing case.

I’ve resorted to this when using the awesome pry debugging tools fails to help me successfully dive deep inside of the Rails save process.

Here’s my overall order of debugging:

  1. Print statements (see above tips), especially “fenced debug statements”.
  2. Examining the failing log file in addition to what’s on the console.
  3. Using pry especially with my setup, which I’ve shared.
  4. Log comparison discussed in this post.