Detect N+1 Queries Early with Rails 7’s strict_loading

Why N+1 Queries Matter

When a Rails application loads a record and then accesses an association without eager loading, each access can trigger a separate SQL query. This pattern, known as an N+1 query, inflates response time and puts unnecessary load on the database. Detecting these issues late in the development cycle often means they reach production before being noticed.

How strict_loading Works

Rails 7 introduced strict_loading as a runtime guard that validates whether an association has been pre‑loaded. When enabled, Rails wraps each association reader with a check: if the association was not eager‑loaded, an ActiveRecord::StrictLoadingError is raised immediately. This turns a latent performance problem into an explicit failure during development or testing.

The feature is controlled via the configuration:

# config/environments/development.rb
config.active_record.strict_loading_enabled = true

Worked Example
Consider a simple blog model where a Post has many comments. Without eager loading, accessing comments triggers a separate query for each post.
# app/models/post.rb
class Post < ApplicationRecord
  has_many :comments
end

In a controller action we might write:
# app/controllers/posts_controller.rb
def index
  @posts = Post.all   # no includes
end

With strict_loading enabled, iterating over the posts and accessing the association will raise an error:
# rails console
> Post.first.comments
# => ActiveRecord::StrictLoadingError: Post is marked as strict_loading and the comments association is not loaded.

Fixing the issue is straightforward: eager load the association.
# app/controllers/posts_controller.rb
def index
  @posts = Post.includes(:comments)   # now safe
end

Trade‑offs and Limitations

  
Overhead: The runtime check adds a small CPU cost; therefore the feature is intended for development and test environments only.
  
False positives: Certain associations—such as polymorphic belongs_to or has_many :through relationships—may need explicit whitelisting via strict_loading_mode: :n_plus_one_only or custom guards to avoid spurious errors.
  
Legacy code: Existing projects that rely on lazy loading for performance‑critical sections may need refactoring before enabling strict_loading.

Getting Started

  
Enable strict_loading in the environment files you want to guard (typically development.rb and test.rb).
  
Run your test suite or start the server and notice any ActiveRecord::StrictLoadingError exceptions that surface.
  
For each error, add the appropriate includes, eager_load, or preload to the originating query.
  
Optionally, whitelist associations that are known to be safe to lazy load:

# Example whitelist in an initializer
ActiveRecord::Base.strict_loading_mode = :n_plus_one_only
Post.strict_loading_associations = [:comments]   # only comments are checked

After addressing the reported errors, verify that the application behaves as expected and that no new strict_loading exceptions appear during normal operation.