// the find
zoolutions/sidekiq-unique-jobs
Prevents duplicate Sidekiq jobs
A middleware gem that stops duplicate Sidekiq jobs from running concurrently or piling up in the queue, using Redis-backed locks keyed on job class and arguments. It's for anyone running Sidekiq at real volume who's been bitten by double-charging, double-emailing, or overlapping job races — the lock granularity (enqueue vs execution vs both) covers most of the dedup patterns people actually hit in production.
v9 cut the Redis footprint from 13 keys per lock down to 2, which matters once you have thousands of locks live at once. The five lock types (until_executing, until_executed, until_expired, while_executing, until_and_while_executing) map onto distinct problems instead of forcing one generic 'unique' flag to do everything. ReliableFetch handles the crash-recovery case Sidekiq itself doesn't — atomic LMOVE plus lock-aware acknowledgment means a killed worker doesn't leave a stuck lock blocking the retry. The Web UI tab and reflection callbacks give actual visibility into lock state, instead of having to query Redis directly to figure out why a job didn't run.
The default behavior silently drops duplicate jobs (on_conflict: :log) — fine until you realize weeks later that a chunk of expected jobs never ran and nothing errored. Lock TTL defaults to nil (no expiry), so a crashed process the reaper misses can leave a lock stuck indefinitely, quietly blocking every future job for that key. v9 dropped Sidekiq 7 and pre-3.2 Ruby outright, so anyone not already current is doing two upgrades before touching this gem. It reads as effectively a one-person project (PayPal link front and center in the README), which is a real bus-factor concern for a library sitting directly in the job execution path.