Sidekiq unique jobs with lock_expiration not working as intended

I'm having an issue with lock_expiration and sidekiq unique jobs.

gem 'sidekiq', '4.2.10'
gem 'sidekiq-cron', '1.2.0'
gem 'sidekiq-unique-jobs', '6.0.25'

With the sidekiq options of:

sidekiq_options queue: :medium, retry: 3, lock: :until_executed, lock_expiration: 120 * 60

When this worker has been run:

[1] pry(main)> HardWorker.perform_async
=> 53b93f122fddbb2ebd350332267484ea

The job completes as the perform is an empty method. The lock happens i.e. I see this in redis: Redis keys

If the AVAILABLE key still exists in redis i.e. before the 5 seconds TTL expires. I can enqueue another job and continue to do this as long as I refresh that TTL and that key exists. However, after the 5 seconds and that key expires I cannot enqueue another job until the EXISTS key expires.

I expect to be able to enqueue another job after 5 seconds has passed. I'm pretty sure that the EXISTS key should be removed after the job completes correctly. But this doesn't happen. The job is able to be enqueued but only within the TTL of the AVAILABLE key.

I am in the process of upgrading sidekiq from a really old version. This is as far as I can go without upgrading other major parts of the system.

My question is, is this intended behaviour? Base on the upgrade we've done and the substitution of config attributes. It should work how it worked before. I.e. being able to queue a job up after completion of current job.

Assuming this is either a bug or intended behaviour. How can I get this behaviour?


I believe your understanding is correct, and the lock should be clearing up as soon as the worker's perform method has been called (based on the semantics described for the until_executed strategy in the docs). If that's not happening, you may be encountering a bug.

However, version 6.x of sidekiq-unique-jobs is described by its author as "the worst mistake I ever made as a software engineer" (https://github.com/mhenrixon/sidekiq-unique-jobs/issues/553#issuecomment-732719189) and "not stable" (https://github.com/mhenrixon/sidekiq-unique-jobs/issues/553#issuecomment-733151792). I would recommend upgrading to at least 7.x before pulling more of your hair out trying to solve this issue.

(Alternatively, if it's an option, Sidekiq Enterprise comes with unique jobs support that's shown itself to be effectively bulletproof in my experience.)