Debugging Rails Controllers with Conditional Breakpoints in RubyMine

Problem: catching a rare request parameter error

When a Rails controller occasionally receives a malformed parameter, reproducing the issue with puts or byebug can be noisy. You need a way to pause execution only when the parameter matches a specific condition, inspect the surrounding state, and continue without altering the codebase.

Thesis: RubyMine’s graphical debugger lets you set conditional breakpoints and inspect live objects, making complex Rails debugging faster and less intrusive than ad‑hoc logging.

Setting up the debugger

1. Ensure your project’s Gemfile includes the debugger gems (they are added automatically when you run a RubyMine debug configuration). Typical versions that work with Ruby 3.2+ are:
• debase (~> 0.2.5)
• ruby-debug-ide (~> 0.7.0)
2. Open Run → Edit Configurations…, click the **+** button and choose Rails Server or RSpec as needed. RubyMine will create a configuration that launches the process with the ruby-debug-ide agent.
3. Start the configuration (click the debug bug icon). The Debug tool window appears at the bottom, showing Frames, Variables, and Watches panels.

Worked example: conditional breakpoint in a controller

Suppose you have a UsersController#update action that fails only when the params[:user][:email] value contains an unexpected character.

1. Open app/controllers/users_controller.rb and place the cursor on the first line of the update method.
2. Click the gutter to add a breakpoint, then right‑click the breakpoint icon and select More… → Condition.
3. Enter a Ruby expression that evaluates to true only for the malformed case, for example:

params.dig(:user, :email) =~ /[^\w@.+-]/

4. Click Done. The breakpoint icon now shows a condition symbol.
5. Trigger the action (e.g., submit a form with a bad email). Execution stops only when the condition matches.
6. In the Debug tool window:
• Inspect params and session in the Variables pane.
• Add a watch for flash[:alert] to see what the controller will set.
• Use the Evaluate Expression dialog (Alt+F8) to try out fixes without changing source.
7. Press F9 (Resume) to let the request continue after inspection.

Trade‑off and limitation

The debugger introduces two practical considerations:

• Gem overhead: Adding debase and ruby-debug-ide to the bundle increases startup time and memory usage. For trivial debugging (a single line check) a quick puts may still be faster.
• Version compatibility: New Ruby releases sometimes outpace the debugger gems. If you upgrade to a Ruby version newer than the gems support, the debug configuration may fail to start until the gems are updated. Check the JetBrains RubyMine release notes for the specific version you are using (e.g., RubyMine 2024.3 supports Ruby up to 3.3 with debase 0.2.5).

To verify that the debugger is working on your machine:

1. Run bundle list | grep -E 'debase|ruby-debug-ide' in the project directory to confirm the gems are present.
2. Start a debug configuration and confirm the Debug tool window shows Connected status.
3. Set a simple unconditional breakpoint, run the app, and ensure execution stops.

Actionable closing

For Rails developers who frequently need to trace multi‑frame issues — such as conditional validation failures, complex callbacks, or intermittent request‑specific bugs — RubyMine’s graphical debugger with conditional breakpoints offers a repeatable, low‑noise workflow. Add the debugger gems, create a debug configuration, and use the condition field to isolate the exact scenario you want to inspect. When the debugging session ends, simply stop the configuration; no code changes or cleanup are required.