peek

[ronag]

Would be nice if a worked could peek a task before actually trying to process it. i.e. to check whether or not it can process it.

[cbraynor]

This is interesting - perhaps something like reject(false) on the processing function or some other sentinel value to indicate that the job wasn't processed but it didn't fail either.

In this case though, there's nothing stopping the first worker from picking up the job again. Actually, it has a very tiny advantage in that it knows before any other worker that the task is up for grabs again. In that case, it's possible (though not probable) the worker will get into a loop and never process the item and also not process any other requests, but at the very least it might spin its wheels for a while.

Another possibility might be to have another function you pass in to the constructor that performs some kind of evaluation on each task - only new tasks that also pass the predicate are consumed by the worker.

In your use-case, is it easy to determine whether the job can be processed, or does it require some asynchronous or time-consuming operation?

[ronag]

I don't see why whether it is time consuming or not is an issue as the predicate check could (should) be a asynchronous operation.

In my use case the check is whether the worker has a specific file in its cache.

[cbraynor]

I asked because it changes the implementation details of the predicate check - if it's synchronous and quick (like a lodash predicate function for example) it could be inside a Firebase transaction function, which is where the worker claims a task. Any code in there could be run many times for every attempt to claim a task (the transaction is essentially a compare and swap implementation). A worker won't ever even claim a job it can't process, so there are no race conditions and it fits really easily into the current model.

If it's slow or asynchronous, the check will have to be after the job has been claimed but before it starts being processed. It will take a significant reworking and could slow every task down (a worker will have to claim it before checking if it can process it, and then discard it before possibly claiming it again, ad infinitum) not to mention the additional possibility of the worker claiming another job while the predicate is running. This is basically the same issue described with the reject(false) suggestion above. It could be worked around with some additional checks to see if the task has been attempted before, but it gets ugly quick.