PRIMED key grows indefinitely when job re-queues itself in `after_unlock` callback about sidekiq-unique-jobs HOT 1 OPEN

Yes, redis suggests a simpler algorithm, but I needed more, so I dreamed up my own algorithm.

People requested that they lock only during runtime, not during queuing, meaning sidekiq picks the job up, runs it through the server middleware, and the server constrains any duplicates from running simultaneously.

People also requested that the locks stay active as long as the job is in Sidekiq. If you want something simpler, I recommend https://github.com/rwojsznis/sidekiq-lock or sidekiq-pro if you have the money.

I don't think you should schedule a new job as part of the old one still running. Sidekiq needs to be done processing the current job when you push the next one. Preferably, you should do that outside of this "Redis transaction" or "unit of work."

The queued and primed keys are used to block as part of processing the job. The push of "1" is accompanied by an expiration to ensure that listeners on the queued key can keep listening.

There are things I can do to improve your situation, but you know you are doing an infinite recursion, right?

from sidekiq-unique-jobs.