Open millerjs opened 3 years ago
In the redis world a value of 0 would block indefinitely and nil would crash with invalid argument.
I found myself wanting zero as default (don't wait). To be perfectly honest though, there is absolutely no circumstances I can think of that would warrant to wait indefinitely. At least not for what this gem does so perhaps zero and nil should be treated the same and any positive integer would block.
@mhenrixon gotcha, that makes sense.
We're definitely not setting nil
, but I've got no idea if other people want that. The fact that nil
is unexpectedly non-blocking suggests it's not a highly used feature 😁
The way I was thinking was that if the key is not set it would mean a default of 0 and explicitly setting the key to nil would allow someone to forcefully wait indefinitely.
I left it in there as a last resort but I should probably restrict it to a positive integer value.
Bug Description
The README says
lock_timeout: nil # lock indefinitely
, but https://github.com/mhenrixon/sidekiq-unique-jobs/blob/620fe7503f1d0395cad337d2e45681504913c7ef/lib/sidekiq_unique_jobs/locksmith.rb#L273-L277 executes a non blocking call ifconfig.timeout
isnil
.Are these two things contradictory?
Expected behavior When
lock_timeout
isnil
, lock acquisition will block indefinitelyCurrent behavior When
lock_timeout
isnil
, lock acquisition is non-blockingWorker class
Additional context
I would expect a spec like this to hang for "indefinitely"
original comment https://github.com/mhenrixon/sidekiq-unique-jobs/issues/617#issuecomment-883458295