Unique key inconsistency between server and client

[elhu]

Hi,

I encountered a problem today while trying to use this gem, when using custom uniqueness parameters, I found that the key added to Redis to enforce uniqueness isn't the same as the key later deleted by the server.
In my case, this means that once my first job is pushed to the Sidekiq queue, no more jobs can be added even after the first one is processed, since the lock key is still present in Redis.

It might be because of another middleware misbehaving, but I believe sidekiq-unique-jobs should be able to avoid this kind of deadlock.
After looking a bit at the code, I saw that the name of the key used to enforce uniqueness is added to the job's payload. Is there a reason why this key isn't then used by the server to perform the unlock, instead of trying to recompute it?

I'd be happy to provide a pull-request if you want.

Thanks a lot in advance !

[mhenrixon]

The idea was to lock jobs with a key that is potentially different from the job key but I'd be real interested to see what you could come up. This is a problem right now so if you have any ideas please do share.

[mhenrixon]

15c2142 might help with that?

[elhu]

I'm going with elhu@7b09226 for now. It's working in my use-case, and I have yet to notice any drawback.

I'd be happy to send a PR if you think it's a good solution for the problem at hand!

[mhenrixon]

I believe this was fixed during the weekend.