Difference between :until_and_while_executing vs :until_executed is not clear

[ragesoss]

I've reviewed the README several times, and I'm still not clear on what the difference is between :until_and_while_executing and :until_executed.

They seem like they mean the same thing: the job is locked — with duplicates being discarded — from the time it first gets added to a queue until the time it has finished being processed.

[lagr]

I was as confused as you are, but I think the old readme highlights the difference a bit better than the current one:

This lock is exactly what you would expect. It is considered unique in a way until executing begins and it is locked while executing so what differs from UntilExecuted?

The difference is that this job has two types of uniqueness:

It is unique until execution
It is unique while executing
That means it locks for any job with the same arguments to be persisted into redis and just like you would expect it will only ever allow one job of the same unique arguments to run at any given time but as soon as the runtime lock has been acquired the schedule/async lock is released.

I interpret this as "While you cannot enqueue a duplicate job A' while job A is either enqueued or running with :until_executed, with :until_and_while_executing you can enqueue job A' while job A is running – as long as job A is no longer enqueued."

With other words, there are two locks at until_and_while_executing which are set at the same time (when a job is enqueued), but the uniqueness constraint on the queue is lifted as soon as the job leaves the queue.

[ragesoss]

Thanks! I guess part of the updated description got accidentally cut out or something.

[mhenrixon]

Sorry about that, the README is on my todo list to update.

[lagr]

Thanks for investing your time in this useful piece of code @mhenrixon!

[ragesoss]

Yes, thanks!

[mhenrixon]

I've updated the readme. I hope it makes more sense how I word it since the recent changes. Please let me know if not.