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:

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?