Issue with until_and_while_executing lock when job is not enqueued through sidekiq

[schwerdt]

Is your feature request related to a problem? Please describe.
Recently, we observed an issue with the until_and_while_executing lock. We were using this lock as our default configuration in the sidekiq initializer, so it was applied to all workers where we did not explicitly change the lock, as expected.

Jobs for one of our workers, however, are not enqueued through sidekiq but are pushed directly to redis (using scout. The behavior we observed is this:

1. The job is published to redis by scout - but without creating a lock.
2. The job is picked up for processing.
3. sidekiq-unique-jobs tries to remove the lock so that it can create the runtime lock here which returns false and goes to the else statement
4. The perform function is never called but no error is raised so the job appears to complete successfully.

The solution we are using is to explicitly use no lock for this worker. We could also possibly use the while_executing lock.

The main issue was that we were not expecting the job to fail to execute the perform function and also fail silently.

Describe the solution you'd like
In the until_and_while_executing lock, do you think it makes sense to check if a lock is locked? before attempting to unlock it. I understand why it could be a problem if unlocking fails (the lock will live on). If the lock was never present to begin with, though, is it harmful to try to create the runtime lock anyway and run the job?

I realize it's unconventional to enqueue jobs this way (enqueue directly to redis), so I wanted to learn what your thoughts are on this idea.

Could there be a check on the presence the lock before attempting the unlock?

 locksmith.locked?

Describe alternatives you've considered
As an alternative, it might be helpful to have a logging statement or an error if the job fails to execute because the lock can not be unlocked.

Additional context