Documentation of lock_ttl is inconsistent

[pboling]

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.

Lock TTL decides how long to wait at most [after enqueueing a job] before considering a lock to be expired and making it possible to reuse that lock.

Starting from v7 the expiration will take place when the job is pushed to the queue.

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

[pboling]

@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.

[mhenrixon]

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.

[pboling]

Oh, I should have remembered that! Enjoy!! 🎁

[mhenrixon]

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.

[pboling]

It's not an urgent matter, don't stress. We actually ended up removing the lock_ttl from most of our jobs because we were using it as a band-aid for other poorly designed things, and we have now fixed those things. Thanks for all your hard work on this!