What is the exact behavior?

[sgringwe]

Great gem, thank you for making it.

I have been looking through the code and reading up and can't figure out precisely what the behavior of this gem is regarding what it looks at when determining whether or not to keep or throw away a job. Which already existing jobs are considered? There are processed, failed, busy, enqueued, retries, scheduled and dead jobs. Which of those does this gem care about when deciding whether or not to keep the second job?

Also, if a job is part-way through/currently being processed, what is the behavior? In my case I want the second job to be kept if the first job is already started as the second job may have new information that makes the first job out of date.

Thanks again.

[mhenrixon]

To answer your second question that is what I would like to, delete the old job and schedule the new one. Would be happy to accept a pull request for that.

The lock is supposed to be kept for t time and when the lock as expired new jobs with the same lock key can be scheduled. Unfortunately working with the scheduler for instance isn't something we do very well if at all right now but I've got plans for that. Currently the lock can be kept until the job is started, the job is ended or until timeout.