Delayed::Job no longer defined in initializers

[severin]

We have some initializers in our app that do schedule recurring jobs if they are not scheduled yet (using the delayed_job_cron gem under the hood), so basically code like this:

# config/initializers/recurring_jobs.rb

if Delayed::Job.where('handler LIKE "%SomeRecurringJob%"').blank?
  Delayed::Job.enqueue(SomeRecurringJob.new, cron: '* * * * *')
end

Since 4.1.5 this results in NameError: uninitialized constant Delayed::Job. Looking at the changes it is very probably due to #172 which changed the requireing of the relevant code to only happen after initialization.

[severin]

I can work around the issue by adding

require 'delayed/backend/active_record'
Delayed::Worker.backend = :active_record

at the beginning of the initializers, but that does not feel right.

[orien]

I have a similar problem. I'm configuring the reserve_sql_strategy option as detailed in the readme:

delayed_job_active_record/README.md

Line 30 in 001b246

Delayed::Backend::ActiveRecord.configuration.reserve_sql_strategy = :default_sql

This has been working till version 4.1.5 where it produces an error:

/my-rails-app/config/initializers/delayed_job.rb:3:in `<top (required)>': undefined method `configuration' for Delayed::Backend::ActiveRecord:Module (NoMethodError)

Adding the require also resolves it.

This does seem related to the change in #172.

[ansonhoyt]

My initializers broke with uninitialized constant Delayed::Job too.

I've never used one, but I think we could move our initializer to be an after_initialize block. Just have to make sure it is defined after the Delayed Job railtie defines its after_initialize block. Looking at https://guides.rubyonrails.org/configuring.html#initialization-events, I don't see when my configs are run, so I'm not sure if an after_initialize added to my config file would run after theirs (they execute in order). Maybe I can simply define the after_initialize in my current initializer. Initializers are clearly run after gems are loaded and their railties are run.

[ansonhoyt]

Yep, this seems to work for me:

# config/initializers/delayed_job_extensions.rb
module DelayedJobExtensions
  # my customizations
end

- Delayed::Job.prepend DelayedJobExtensions
+ Rails.application.configure do
+   config.after_initialize do
+     Delayed::Job.prepend DelayedJobExtensions
+   end
+ end

No errors and my customizations are available in the console. I think you could do something similar.

[ansonhoyt]

I would be nervous simply adding a require to your initializer. Looking at #172, you'll possibly reintroduce that issue to your app.

[albus522]

I forgot that change hadn't been released. I need to circle back and update the changelog and probably add more documentation.

If you can, wrap what you need to run in an after_initialize like @ansonhoyt suggests, that will be the safest bet and your block will run after DJ's because DJ's is setup when the Bundler.require(*Rails.groups) runs in application.rb.

If you can't use after_initialize,

require 'delayed/backend/active_record'
Delayed::Worker.backend = :active_record

will work, however make sure your initializer runs after any other ActiveRecord configuration initializers. The app initializers are usually run in alphabetical order by filename, so this can usually be accomplished by prefixing your initializer filename with z's like zzzzz_my_late_run_intializer.rb. There are a number of ActiveRecord configuration items that won't apply after ActiveRecord loading triggers and the rails team refuses to consider that a bug.

[jdelStrother]

make sure your initializer runs after any other ActiveRecord configuration initializers. The app initializers are usually run in alphabetical order by filename, so this can usually be accomplished by prefixing your initializer filename with z's like zzzzz_my_late_run_intializer.rb. There are a number of ActiveRecord configuration items that won't apply after ActiveRecord loading triggers and the rails team refuses to consider that a bug.

Wouldn't something like this be a better way of accomplishing that?

ActiveSupport.on_load(:active_record) do
  require "delayed/backend/active_record"
  Delayed::Worker.backend = :active_record
end

[albus522]

ActiveSupport.on_load(:active_record) won't work reliably because that relies on something triggering ActiveRecord to load. If nothing triggers the load, DJ never gets setup.

[jdelStrother]

Ugh - yeah, ok. Can't see it happening in production due to eager loads, but I guess it might cause problems in development.

[thoughtafter]

I ran into this. This is a breaking change in a patch update. I'm not sure if the version numbers are locked to delayed_job but I definitely did not expect this update to break my app. I haven't fully grokked #172 so maybe this is a good path forward but probably some warning and documentation about breaking changes and the pros/cons of different fixes might be warranted.

[philayres]

I think this may have caused the following in my app when I upgraded from 4.1.4 to 4.1.5 last night: undefined method `where' for Delayed::Job:Class (NoMethodError) Did you mean? when. I'm adding this in case anybody else tries to search the error.

The error occurs in an initializer, so I added the block as suggested:

Rails.application.configure do
  config.after_initialize do
    # original code
  end
end

This seems to work (at least Rails will start now).

[philayres]

This also broke for me in another way (but only in the production environment). I had a small utility class that inherited from Delayed::Job like this:

class JobReview < Delayed::Job
    # implementation
end

In development it loads fine, but in production this causes the unitialized constant issue. Obviously wrapping this the same as above for initializers doesn't make sense. I use this rarely, so for now I have just removed the class, but others may come across this if inheriting Delayed::Job for some reason.

[skipchris]

Seconding/thirding the comments above. This may well be the ‘right’ change, I haven’t had a chance to properly digest the issue, but making a breaking change in a minor version bump is a bit much!

[jacobjlevine]

Don't know if this will be helpful for all of you, but I had an initializer that broke with this update and I was able to find a relatively straightforward resolution as detailed in this issue: #188.

[seandilda]

I'm also seeing this, but with the error:

NameError: uninitialized constant Delayed::DelayProxy::Job

This happens if you try to use #delay method to delay a method call. I'm adding it to the thread for anyone else searching for the error.

[albus522]

Ok. I was hoping to come up with a better solution, but didn't, and time got away from me. I have pushed out 4.1.6 which only rolls back the loading change. Using after_initialize should not break with the update, but it will no longer be needed.