Within tests: workers enqueued in the future don't clear their unique locks after being drained/executed

[axsuul]

On 5.0.10, if I have a worker defined as such

class TestWorker
  include Sidekiq::Worker

  sidekiq_options unique: :until_executed

  def perform

  end
end

and within my tests, having the worker enqueued in the future doesn't seem to clear the unique lock once it is drained:

# passes
expect { TestWorker.perform_in(10.seconds) }.to change { TestWorker.jobs.size }.by(1)

# this executes the job
TestWorker.drain 

# fails but it should enqueue since the first worker has been executed already
expect { TestWorker.perform_in(10.seconds) }.to change { TestWorker.jobs.size }.by(1)

Running this within a live Sidekiq process seems to work as expected. It's just that within tests, it fails. If I add a sidekiq_options unique_expiration: 1.second, it does pass but it kind of defeats the purpose of the unique lock. Is this a bug?

[mhenrixon]

@axsuul it looks like your are combining two different ways of doing things (not compatible). I suspect the unique key is created in sidekiq and not removed by TestWorker.drain.

I've been meaning to enhance this forever. Try require 'sidekiq_unique_jobs/testing'. It isn't working perfectly though but it works better than if you haven't required it yet.

[mhenrixon]

In version 6 you will have to disable uniqueness for testing since supporting all sidekiq versions with various monkey patching is just too complicated. You will have to trust the gem or test similarly as I do in the gem if you truly care.

I'm closing this for now