Skip to content


Delayed::DeserializationError if a method parameter is an unsaved ActiveRecord object #619

cyrilchampier opened this Issue · 5 comments

3 participants

/Users/augment/.rvm/gems/ruby-2.0.0-p247@ruby2.247/gems/delayed_job-4.0.0/lib/delayed/psych_ext.rb:112:in `rescue in visit_Psych_Nodes_Mapping_with_class'

why not just unserialize the object instead of trying to fetch the current version ?

as said here:

"it's not a bug, it's a feature"

but why not simply fallback to 'visit_Psych_Nodes_Mapping_without_class' if id is nil ?


it seems that it has already been decided that it's "not a bug":

I still do no understand what concurrency issues can arise.

Would it be possible to add a configuration ?
something that would allow to consider ActiveRecord object as simple hashes ?

Collective Idea member

Yes this is intended. It will NOT change.

For one of many examples, say you have a new record, you delay something on that record. After the job is sent off you save that record. Then in the job you do stuff and save the record. Now you have 2 records based on the same root record that you probably didn't intend.

@albus522 albus522 closed this

If the active record object is converted to a hash, there wont be such problem

Collective Idea member

@cyrilchampier This is an edge case that almost always signals a bug in the caller's code. If you have a case where you want to delay the creation of an object, just write a custom Job that takes a hash of attributes.


If I remember well, I wanted to send a mail after the deletion of an user.
When the job triggers, the user had been deleted.
Yes I took the solution of rebuilding an object with user interesting properties.
Just wished it was automatic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.