Manuel Astudillo

Note that we have the timeout option currently, but does address the two issues mentioned above.

Not really. In fact this TTL functionality could work really well after #488 is ready, since it will allow us to actually kill the process that has exceeded the TTL...

The original implementation of priority queues used a queue for every priority, but it gets messy and difficult to avoid all special cases. The current implementation is much more solid...

@zebulonj they are not good enough because they just pop the element from the set, so if the guy popping the element dies for some reason, that job will be...

but if we do not care about blocking then it is trivial, we can just have a command that consumes from ZSET and pushes in LIST atomically using lua.

@misos1 do not worry, I won't close issues that are legitimate bugs.

Well I guess that should be like any other debouncing, i.e. if the job already started it will continue working, and the job added after that should be either ignored...

https://issuehunt.io/r/OptimalBits/bull/issues/1034

@mauricedoepke I am going to look into it, it was long time ago so I barely remember it anymore.

@mauricedoepke just to make clear the requirements for this issue: 1) A job added with a debounce parameter will wait X milliseconds before starting to process. 2) If a new...