opened
axsuul
username_0
On `5.0.10`, if I have a worker defined as such

```ruby
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:

```ruby
# 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?
Within tests: workers enqueued in the future don't clear their unique locks after being drained/executed
issue
created
mhenrixon
username_1
@username_0 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`.
comment
created
mhenrixon
username_1
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
comment
closed
mhenrixon
username_1
issue