-
-
Notifications
You must be signed in to change notification settings - Fork 277
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
Documentation of lock_ttl is inconsistent #831
Comments
@mhenrixon Sorry to bump here after such a long couple days in the trenches, but I'm really hoping I can clear this up in my head. |
My youngest turns five today 🎂🎉🎈🥳 Since this is such a complicated topic, the documentation is lacking. My daughter turns 5, and I haven't looked at this for a long time; it will have to wait until tomorrow. I have no idea what I meant with the documentation there, but as you pointed out, it is, at best a fraction of the entire truth. Each job has a different expiration logic. I will have to get back to you tomorrow when I've had some time to look deeper. |
Oh, I should have remembered that! Enjoy!! 🎁 |
Gosh, life tends to get you. So, yesterday was Valentine's Day, and today I have a few phone calls and must travel to the city for a bit before I can finally get to this. I had another look at the docs but I simply don't understand. I know there are differences in the expiration between lock implementations, so I need to check the tests and rewrite the docs. |
It's not an urgent matter, don't stress. We actually ended up removing the |
Documentation of
lock_ttl
has evolved over time in various places in the readme, and now seems to describe somewhat different things depending on where you look.Confused about "when the job is pushed to the queue". If a new job being pushed to the queue clears the lock then what is the lock for?
See also: #593
The text was updated successfully, but these errors were encountered: