Ruby Reaper deletes :until_expired locks before their TTL has elapsed

[francesmcmullin]

Hi again 👋🏻 First, thanks so much for the amazingly fast fix on #653 , it's deployed and working perfectly. Or maybe too well =(

Describe the bug
Jobs configured with lock: :until_expired and a ttl can be run multiple times inside the ttl period if the ruby reaper is running.

Expected behavior
For jobs using lock: :until_expired, I shouldn't be able to enqueue them again for ttl seconds after it was last enqueued (regardless of run time or success).

Current behavior
After 1. the job has run and 2. the ruby reaper has run (or been manually invoked), I can enqueue the job again.

Worker class

class MyWorker
  include Sidekiq::Worker
  sidekiq_options lock: :until_expired, ttl: 600, queue: 'default'
  def perform(args); end
end

Example:

> MyWorker.perform_async('blah')
=> "d3ed4d6c9f862da5092250a9"
> MyWorker.perform_async('blah')
=> nil
> SidekiqUniqueJobs::Orphans::Reaper.call
=> 1
> MyWorker.perform_async('blah')
=> "bc29e0d80ad086d14245cafd"

Additional context
Sidekiq version: 6.2.2
Sidekiq-unique-jobs version: 7.1.11

Also I've opened this as a bug, but freely accept I may have misunderstood how either until_expired or the reaper should work.

[mhenrixon]

That is an oversight by me, might have to check the TTL before and not delete if such exists.

[mhenrixon]

This is resolved in the current version. The expiring_digests sorted set now stores the future expiry timestamp as the score (current_time + pttl), and the reaper only deletes entries with score < current_time. Added a regression test in #939 confirming until_expired locks are not reaped before their TTL elapses.