-
-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic unlock of jobs #362
Comments
This has been discussed to death (pun intended). There is absolutely nothing the gem can or should do about this. If the job is back in redis it should still be considered unique because it will be retried. |
If you feel like having a scheduled job to clear out jobs it is all on you :) I might create a better functionality for finding and clearing such jobs manually in the future but there needs to be manual intervention here. This is what Mike Perham does with the pro and enterprise versions of sidekiq. |
Is your feature request related to a problem? Please describe.
When sidekiq process is killed (SIGKILL) everything stays as-is in Redis. Sidekiq has mechanism of heartbeats to check if processor is still running or not. The same should apply for the unique jobs.
Describe the solution you'd like
I suggest some job that would periodically (e.g. every minute) check whether the unique digest lock is still valid = whether it is assigned to some running job. This would require to store also "JID" to each unique digest so that they can be paired together.
If the job is not running anymore it means the unique digest is stale and should be removed.
Otherwise it is blocking all future jobs until manual removal. I would like to prevent this manual removals by implementing this "auto-heal" feature.
The text was updated successfully, but these errors were encountered: