Usage of sidekiq-unique-jobs with activejob

[matthijsgroen]

To use the uniqueness with active job:

Sidekiq.default_worker_options = {
   'unique' => true,
   'unique_args' => proc do |args|
     [args.first.except('job_id')]
   end
}
SidekiqUniqueJobs.config.unique_args_enabled = true

Maybe you can update the readme for this?

[acegilz]

+1

[mhenrixon]

Thanks: https://github.com/mhenrixon/sidekiq-unique-jobs#usage-with-activejob

[IanVaughan]

The readme does not include the SidekiqUniqueJobs.config.unique_args_enabled = true, is this required too?

Also, where should this go?

[abacha]

but if I dont want to use unique with all my workers?

[jolim]

I've come up with a hack. It's flexible, so you can do what you want with this pattern.

With ActiveJob, it compares all jobs by their argument hash, so all jobs are subject to the action (drop/delay). In the configuration lambda, if you make a job unique by adding a uuid to the arguments hash, the job will not be subject to the action.

You can use any information in the jobs hash. The most interesting ones are the job_class and the queue_name. I've chosen to implement this hack with the latter by putting jobs onto a queue that I've named unique_jobs. You can create any queue name you want, or test if the [<class names>].include? r['job_class'] or whatever else makes you happy.

Sidekiq.default_worker_options = {
  unique: :until_executing,
  unique_args: lambda { |args|
    r = args.first.except('job_id')
    r[:make_unique] = SecureRandom.uuid unless r['queue_name'] == 'unique_jobs'
    [r]
  }
}

[mhenrixon]

I strongly recommend people to use sidekiq directly and not bother with active job. Why settle for a Fiat when you can drive a Ferrari?

[EPecherkin]

This comparison doesn't work here. It is all about a vendor-lock, which is always bad for a big business

[sharshenov]

Here is an implementation for ActiveJob: activejob-uniqueness