Skip to content

until_executed and lock_expiration. #676

@richkettle

Description

@richkettle

Describe the bug
With the sidkiq 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:
Screenshot 2022-01-12 at 12 36 26

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.

Expected behavior
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.

Current behavior
The job is able to be enqueued but only within the TTL of the AVAILABLE key.

Worker class

class Hardworker
  include Sidekiq::Worker
  sidekiq_options queue: :medium, retry: 3, lock: :until_executed, lock_expiration: 120 * 60 # Make the uniq 2 hours

  def perform; end
end

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

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions