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

[cyrilchampier]

Delayed::DeserializationError
/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 ?

Edit:
as said here:
https://github.com/collectiveidea/delayed_job/wiki/Common-problems#dj-doesnt-deserialize-an-unsaved-activerecord-model

"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 ?

[cyrilchampier]

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

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 ?

[albus522]

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.

[cyrilchampier]

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

[betamatt]

@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.

[cyrilchampier]

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.