Option to disable/configure the automatic integration with ActiveJob about bugsnag-ruby

[gustavompo]

I ended up with this hacky-ish approach I'd love to get rid of when this is patched. I opted for that over downgrading to an earlier version. This is also considering we have our own reporting callbacks in place, so all we wanted was to disable the bugsnag one entirely.
This runs as one app initializer:

perform_callbacks = ActiveJob::Base.__callbacks[:perform]
proc_callbacks = perform_callbacks.map { |cb| [cb, cb.raw_filter.source_location.first] if cb.raw_filter.is_a?(Proc) }.compact
bugsnag_callback = proc_callbacks.find { |_cb, source| source.include?("bugsnag/") }&.first
if bugsnag_callback
   ActiveJob::Base.descendants.each do |job_class|
      job_class.__callbacks[:perform].delete(bugsnag_callback)
   end
end

[weiyunlu]

+1, we are having the same problem, retrying a job up to 6 times would now kick off 6 bugsnags which is not a workable level of noise (consequent of which is our engineers on support would be pinged multiple times for the same error), so we are not upgrading to the latest version unless some kind of alternative option is introduced. And please, do :).

@gustavompo I believe this change came into effect on 6.22.0 so if you are able to downgrade to an earlier version you may be able to work around.

[luke-belton]

Hi @gustavompo 👋

Rails doesn’t provide an API that tells us if a job will be retried or discarded. For simple cases it’s possible to find this out, but both retry_on and discard_on can be given a proc which makes this impossible — the proc may have side effects so Bugsnag can’t safely call it.

Therefore Bugsnag can’t know if a job will be retried or discarded and so we report all failures. We also don’t know if a retry or discard is safe to ignore, so would likely be reporting these even if we could reliably determine that the job will be retried or discarded.

An on error callback can be used to ignore events from a job based on the number of times it has been executed. Note this was added in Rails 5, so won’t be available if you’re running Rails 4:

Bugsnag.add_on_error(proc do |event|
  next unless event.metadata.key?(:active_job)

  executions = event.metadata[:active_job][:executions]

  # discard events until at least 3 executions
  # note: 'executions' counts the attempt that triggered this error, i.e. it
  #       starts at '1' and will increase each time
  if executions < 3
    false
  end
end)

This could then be adapted per-job, e.g. using a class method to drive the number of times a job will be attempted:

Bugsnag.add_on_error(proc do |event|
  next unless event.metadata.key?(:active_job)

  executions = event.metadata[:active_job][:executions]
  job_name = event.metadata[:active_job][:job_name]

  job_class = Object.const_get(job_name)

  next unless job_class.respond_to?(:retry_count)

  if executions < job_class.retry_count - 1
    false
  end
end)

It’s also possible to ignore all events from our built-in Active Job handler with a callback like this:

Bugsnag.add_on_error(proc do |event|
  if event.metadata.key?(:active_job)
    false
  end
end)

[weiyunlu]

^ Hi @luke-belton , we attempted to add

Bugsnag.add_on_error(proc do |event|
  if event.metadata.key?(:active_job)
    false
  end
end)

to our bugsnag.rb initializer, however it still seems to trigger automatically in tests, i.e.

 Failure/Error: expect(Bugsnag).to have_received(:notify).once
     
       (Bugsnag).notify(*(any args))
           expected: 1 time with any arguments
           received: 7 times with any arguments

(as a result of six retries in the test automatically notifying Bugsnag). Replacing false with event.ignore! did not work either.

On the other hand, @gustavompo's hack seems to work... however would like to not rely on a hacky patch and prefer a working official config to completely disable the active job automatic triggers.

[xljones]

Hi @weiyunlu 👋 . Bugsnag.notify() is going to be called each time there is an error, but it will be discarding the event in the proc callback. So, in this rspec scenario I would expect the call to notify to be made each time an error occurs, but would not expect said report to actually appear in your Bugsnag dashboard, as it'll be rejected.

Instead, if the notify method is not being stubbed in your tests, you can check to see whether a notification actually did send using a helper method like we do in testing this library: https://github.com/bugsnag/bugsnag-ruby/blob/v6.24.1/spec/spec_helper.rb#L120-L129

This helper is utilized here: https://github.com/bugsnag/bugsnag-ruby/blob/v6.24.1/spec/bugsnag_spec.rb#L75-L78

[johnkiely1]

We have now added the examples mentioned above to our official documentation around modifying/disabling the behaviour of capturing errors associated with active job events.