This is actually an issue with the new yaml serialization/deserialization code. I've updated the issue to reflect the actual problem.

As a short term workaround, require your models in an initializer.

+1 for a fix on this. I feel dirty listing my models in an intiializer.

I'm working on it. The internals of yaml are nasty. But I just need to find where it tries to load the constant and make it use ActiveSupport's class loading

When I require my models in an initializer, I run into another issue when running in development mode where the model can only be loaded for one request before throwing an exception (caused by the activesupport class reloading, I think). Any ideas on how to get around this issue as well?

constantize objects when deserializing so that ActiveSupport can attempt its auto loading magic

Closed by 4c53af8

I presume this has the same root cause as silently removing jobs who's handlers can't be loaded? https://github.com/collectiveidea/delayed_job/wiki/Common-problems#wiki-jobs_are_silently_removed_from_the_database

This is back in DJ 3. Any plans to fix it?

@stevenharman Is this an issue you're experiencing with 3.0.2? We've tried to keep the serialization the same.

@bryckbost Yes. Well, actually, its not with an AR Model, but a custom job. In particular, I have MyCustomJob in app/models/my_custom_job.rb, which looks like

class MyCustomJob < Struct.new(:foo, :bar)
    def perform
      #do interesting stuff here.
    end
end

Which is enqueued thusly

Delayed::Job.enqueue MyCustomJob.new('this', 42)

When trying to unmarshal the handler, it fails and silently removes the job. This took way too long to track down, but explicitly requiring the custom class has "fixed" it.

# config/initializers/delayed_job.rb
require 'my_custom_job'

All of this started upon upgrading from 2.x to 3.0.

I have run into this on latest 3.x, after changing my yaml engine to syck from psych.

Explicitly requiring classes in an initializer fixes it, but is not a solution I am happy about.