Call stack not useful when in test mode

[mockdeep]

When I enable Bullet in test mode, the call stack just points to the place in rails_helper.rb where we have Bullet.perform_out_of_channel_notifications. Is there a way to get a meaningful call stack for this? It would be nice if we could just run it the same as in dev mode.

AVOID eager loading detected
  RecipientStep => [:form_requests]
  Remove from your finder: :includes => [:form_requests]
Call stack
  <projectdir>/spec/rails_helper.rb:144:in `block (2 levels) in <top (required)>'
  <projectdir>/spec/rails_helper.rb:197:in `block (3 levels) in <top (required)>'
  <projectdir>/spec/rails_helper.rb:196:in `block (2 levels) in <top (required)>'

[gagalago]

I have that kind of error but if I force the version of bullet to 5.7.5 the error just disappear.

[NickOttrando]

Same issue on my end, would be really nice to get the stack trace starting from where the query or includes statement is actually made within the application, rather than the stack trace of the spec run.

[victorhazbun]

Same issue here.

[danielnc]

bump

[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) { ... }