← Back to Upcase

ActiveJob and Sidekiq: not finding Job Class


(Brian Dear) #1

Interesting problem with Sidekiq and ActiveJob. this is a R4.2-beta4 app with a job class MyJob.rb – when I call the job inline as MyJob.perform_now – it works fine.

But when I call #perform_later Sidekiq chokes with an uninitialized constant MyJob.

This is a bit new territory, so I’m not sure how to debug this. I would think it might be something to do with load paths, but perform_now is working, so my class is recognized.

I’m thinking that it might be something with the queue name, however the sidekiq dashboard shows the Job, it just show the error as well.

Any theories?


(Geoff Harcourt) #2

@briandear, is the exception thrown when you call #perform_later, or is it when the Sidekiq server attempts to execute the job?


(Brian Dear) #3

Exception thrown within the sidekiq server. The Rails server doesn’t seem to care.


(Geoff Harcourt) #4

(should have asked more questions)

What version of Sidekiq? Can you paste the code for your worker and your Sidekiq initializer?


(Brian Dear) #5
class StripeRunnerJob < ActiveJob::Base
  queue_as :default

  def perform(guid)
    ActiveRecord::Base.connection_pool.with_connection do
      charge = Charge.find_by(guid: guid)
      return unless charge
      charge.process!
    end
  end
end

Sidekiq 3.2.6, Rails 4.2.beta4

No sidekiq initializer – the process starts with the following command:bundle exec sidekiq -q mailers, default

Thanks so much for your help! ActiveJob is still new enough that there isn’t much out there beyond the official docs.

One more sidenote, this job executes perfectly when ran inline, so the job itself “works” it’s just that sidekiq hates it, or actually doesn’t even know it.


(Geoff Harcourt) #6

Without seeing your whole application I can’t be sure, but I suspect what’s going on here is that when you run the job inline from the console that Sidekiq through the console environment has access to the rest of your Rails application, but that the Sidekiq server does not. Can you post your stacktrace?


(Brian Dear) #7

There isn’t much of stack trace: (meaning the job is enqueing in the Rails server) and this is what sidekiq gives me: https://www.dropbox.com/s/svn5r71ykx0hy7u/Screenshot%202014-11-28%2021.33.06.png?dl=0 (totally not helpful, I know.)

This looks similar to this Sidekiq issue (about eager loading): https://github.com/mperham/sidekiq/issues/1791

However, I’m running sidekiq from master branch directly, and that issue was closed with an accepted PR.

So it’s a mystery. Thanks for your attempts to help, but it might appear that we don’t have enough information to solve this one easily. I’m going to attempt to bypass ActiveJob’s plumbing and run through sidekiq directly so I can potentially eliminate something in ActiveJob as a problem, however it appears that ActiveJob isn’t the issue – the job IS getting sent.

I guess broke the internet.


(Geoff Harcourt) #8

Hey @briandear,

Sorry I wasn’t more helpful here. Is there a reason you’re running on the master branch (or is it just to test this fix)? I have been doing a little work to get my app ready for Rails 4.2, and I haven’t used ActiveJob yet (although we rely very heavily on Sidekiq).

Were these failures happening in a staging environment, or just in development?


(Brian Dear) #9

Actually, I haven’t tested on staging just yet (actually I have, but only #perform_now.) I’m running master for sidekiq just to eliminate any potential diff from the latest gem version from the edge version, since Rails 4.2 is still in beta, I wanted to be sure that I wasn’t trying to fix something that had already been addressed. But the behavior is identical between the stable and master.

I’m going to try this stuff out on staging today or tomorrow and perhaps that’ll give us more data. You likely don’t have the time, but if you’re interested, the complete app is here: https://github.com/superacidjax/myhelloworld

Excuse my 77% test coverage. I started this as bit of a proof of concept “spike,” so I didn’t TDD as I normally would have. Although, I am adding more tests. Kind of embarrassing really!

The operations in question are in the charges_controller, the stripe_runner_job and the Charge model. But no need to actually look at the code unless you’re just curious. I realize those particular files are smelly – however, I’m going to write tests before I refactor, since things currently “work” (other than #perform_later.)

You’ve been a rather good partner in just prodding me along, so thanks! Hopefully we’ll solve this, I’m sure I’m not going to be the only one trying to figure this out.