ActiveJobs are all wrapped into one unique report about appsignal-ruby HOT 10 CLOSED

I must admit that we haven't tested with ActiveJob yet. We'll get a testing setup for that together this week and I'll get back to you on this.

from appsignal-ruby.

Sounds good, thanks!

from appsignal-ruby.

Hello,

Is this still the case or has it been fixed since?

Thank you.

from appsignal-ruby.

It looks like this issue was caused by the way Sidekiq integrates with ActiveJob. They've now fixed this in 3.3.4:

Improved ActiveJob integration - Web UI now shows ActiveJobs in a nicer format and job logging shows the actual class name, requires Rails 4.2.2+ [#2248, #2259]

https://github.com/mperham/sidekiq/blob/master/Changes.md

Could you try that version of Sidekiq?

from appsignal-ruby.

@thijsc I will, thank you for pointing this out!

from appsignal-ruby.

It's doing the same for DelayedJob too

from appsignal-ruby.

I'm working on a Que adapter and am wondering how to fix this ActiveJob issue for it. It looks like Sidekiq and DelayedJob integrate with ActiveJob for display purposes, if I'm reading the appsignal source correctly, but how to do that for ActiveJob backends that don't have this feature?

cls = args.last['job_class'] if cls == "ActiveJob::QueueAdapters::QueAdapter::JobWrapper"

in an integration might work, but I wonder how a more general solution would look like.

Also, ideally I'd like to see the actual ActiveJob info in the action arguments (incl. a mention of the JobWrapper class), but have Appsignal split jobs by ActiveJob's class name. Not sure how that would fit in, though.

from appsignal-ruby.

Hi @wvengen do you have an example/code of your Que adapter? I can take a look and see how best to support AppSigal for it :)

from appsignal-ruby.

@matsimitsu sure, feel free to participate in #70. Thanks!

from appsignal-ruby.

We've greatly improved the ActiveJob integration in 1.1, which is now in beta. Could you try that version @rnaud?

from appsignal-ruby.