Repository navigation
Support errors happening in ActiveJob (solid_queue, sidekiq, ...) #44
Description
It would be nice if solid_errors supports ActiveJob. Sentry-Rails could be a good resource of inspiration.
https://github.com/getsentry/sentry-ruby/blob/master/sentry-rails/lib/sentry/rails/active_job.rb
https://github.com/getsentry/sentry-ruby/blob/master/sentry-rails/lib/sentry/rails/railtie.rb
Activity
stillhart commentedon Apr 15, 2024
Or is this the job of the background worker such as solid_queue? If so, I can open an issue in solid_queue
defkode commentedon May 9, 2024
@stillhart I came up with simple integration for ActiveJob (tested with SolidQueue)
https://gist.github.com/defkode/3da234167d1a7bc18a46ff2e700c4d65
npezza93 commentedon Oct 5, 2024
@fractaledmind Been working on my own error reporter too(cause why not 😄) and stumbled on this. Opened up rails/rails#53201 to hopefully fix this and cut down on monkey patching. Action Cable may need something too but havent tested it yet.
kuboon commentedon Feb 28, 2025
Is this solved in SolidQueue?
rails/solid_queue#373 (comment)
npezza93 commentedon Feb 28, 2025
Yep
fractaledmind commentedon Oct 16, 2026
This works without extra setup now. Since Rails 7.1, which is Solid Errors' minimum as of 0.7.1, the Rails executor reports any unhandled error to
Rails.error. Job backends that run jobs inside the executor (Solid Queue, Sidekiq's Rails integration, GoodJob) therefore send job failures straight to Solid Errors. Thanks @npezza93 for the upstream work.#115 also makes those occurrences useful: they record the job class, id, queue and (filtered) arguments, with records as GlobalIDs, instead of
#<MyJob>. The README section it adds describes this.