Serialization interface

I maintain a newer Ruby gem for helping to make Jobs (whether ActiveJob or Sidekiq) more resilient by leaning on ACIDic database transactions: http://github.com/fractaledmind/acidic_job

At the heart of this approach is essentially tracking job runs via a database record. One essential ingredient for this to work is to be able to serialize and deserialize jobs, so that I can store a job run and then start that job with the job queue. ActiveJob provides the following interface which makes this straightforward:

SomeJob.deserialize(some_job_hash)
SomeJob.new(arguments).serialize

I have patched around Sidekiq's lack of a similar interface, but it has required me to essentially copy and re-execute the code in Sidekiq::Client#push (for serialization) and Sidekiq::Processor#dispatch (for deserialization). These are both hacks that are highly liable to break if anything in Sidekiq changes.

I am curious how amenable you are to the idea of working to bringing the same basic serialization interface to Sidekiq?

I should note that there is one major architectural difference that makes this a non-trivial feature—ActiveJob treats the object instance as the primary entity that holds all information, including perform arguments; Sidekiq doesn't put much emphasis on the object instance, and all of the "magic" happens via the perform method. There are no arguments and no jid until perform_async ends up at the Redis push. If you call SomeWorker.new.perform(), you will have no jid

I have worked around this by prepending a custom perform method into Jobs to allow me to capture the arguments such that I can then serialize them. However, a Sidekiq job cannot be initialized with arguments and then make a call to perform. I also manually add my own jid if the job is called synchronously.

So, I wanted to get a sense of your interest in these kinds of features in Sidekiq core before attempting a PR, as I don't see a path to a very cosmetic PR that simply adds serialization. I imagine some re-imaging of the Sidekiq internals would likely be needed, and that is no simple thing.