// the find
mhenrixon/sidekiq-unique-jobs
Prevents duplicate Sidekiq jobs
sidekiq-unique-jobs prevents duplicate Sidekiq background jobs using Redis locks, with configurable lock lifecycles and conflict resolution strategies. v9 is a significant cleanup: down from 13 Redis keys per lock to 2, dropped Sidekiq 7 and Ruby < 3.2 support, added reliable fetch with crash recovery. It's for anyone running Sidekiq who needs at-most-once or at-most-one-concurrent semantics on jobs.
Lock logic implemented in Lua scripts, which means atomicity without Ruby-side race conditions. The five lock types cover genuinely different use cases — :until_executing vs :while_executing vs :until_and_while_executing are distinct and the README explains each clearly. Per-conflict-strategy granularity at client vs server boundary is a real feature: you can log duplicates at enqueue time but reschedule them at execute time. The reflections API gives observability hooks without monkey-patching.
The :replace conflict strategy is a footgun in high-throughput scenarios — deleting an in-flight job to enqueue a new one can silently drop work if the timing is wrong. The lock_args_method lambda approach for custom uniqueness keys has no validation; a bad lambda that returns nil will silently make every job unique or non-unique depending on implementation details. No built-in distributed tracing or metrics emission — lock_info=true stores metadata but you have to scrape it yourself. ReliableFetch is opt-in and underdocumented: the crash recovery behavior on startup could be surprising if you have a large working set from a crashed process.