Bullet does not show stack-trace on test env

[victorhazbun]

When I run the specs I got the following logs which are not complete since they do not include the full stack trace:

Bullet::Notification::UnoptimizedQueryError:
  user: victorhazbun

  AVOID eager loading detected
    AffiliateBrand => [:parent]
    Remove from your query: .includes([:parent])
  Call stack
    /Users/victorhazbun/Code/my-app/spec/support/bullet.rb:12:in `block (2 levels) in <top (required)>'
# ./spec/support/bullet.rb:12:in `block (2 levels) in <top (required)>'

I have the following setup in a spec helper.

RSpec.configure do |config|
  config.before(:each, bullet: true) do
    Bullet.enable = true
    Bullet.bullet_logger = true
    Bullet.raise = true # raise an error if n+1 query occurs
    Bullet.start_request
  end

  config.after(:each, bullet: true) do
    Bullet.perform_out_of_channel_notifications if Bullet.notification?
    Bullet.end_request
    Bullet.enable = false
    Bullet.bullet_logger = false
    Bullet.raise = false
  end
end

NOTE: The full stack trace only appears when N+1 issues occur, but not for unused eager loading issues.

[typhoon2099]

A seem to be having the same issue with one of my projects, but not with another. In the working project I have the following in config/environment/test.rb:

  config.after_initialize do
    Bullet.enable = true
    Bullet.raise = true
  end

I've tried the same in the failing project and it doesn't raise any errors. I've tried your config blocks and get no errors or anything logged. And I've checked Bullet's config inside the test, which was reporting the correct config.

[johansenja]

I was running into a similar same thing, and this was a workaround that worked for me:

module Bullet
  module StackTraceFilter
    # the original method here filters out any items in the stacktrace which aren't from our
    # project, but the trouble is that this can be a bit restrictive, and doesn't allow exceptions
    # for destroy callbacks, for instance.
    def caller_in_project
      select_caller_locations { true }
    end
  end
end

It just patches the stack trace filtering so that none of the items are filtered out (though you could also define some custom logic in the block to fit your use case better - the block can take a param which is the stack trace entry)

If there is interest then I might consider putting together a PR which allows the block to be configurable eg.

Bullet.stack_trace_filter = ->(location) { ... }