[Bug]: Default timeout not documented? Is there one?

[GeoffreyPlitt]

Version

v3.10.2

Platform

NodeJS

What happened?

Is there a default timeout? E.g., if I enqueue a task that hangs (runs forever, never succeeds or fails), without providing a timeout, is there a default timeout? I.e., will the task eventually be considered a "stall" and reset to a state where it will get picked up again by workers?

We see errors in our logs indicating tasks do stall and get reset back to workable state (Missing lock for job 4663). However I cannot find what the default timeout is.

I noticed there was never a resolution for #136.

And there's nothing in the docs about it.

How to reproduce.

No response

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[roggervalf]

hi @GeoffreyPlitt, timeout was not used at all in the code, this is why it was removed, we don't have a mechanism for timeouts in the base version, we tried few things but we got zombie processes. So the only documented way is only available in pro version https://docs.bullmq.io/bullmq-pro/observables/cancelation because we are supporting observables there.

[GeoffreyPlitt]

OK, so there's no timeout, good to know. For anyone else having this issue, you can add timeouts yourself with NPM module promise-timeout.

[manast]

OK, so there's no timeout, good to know. For anyone else having this issue, you can add timeouts yourself with NPM module promise-timeout.

It is important to note that promises in Node are not cancelable, so when using promise-timeout you risk leaving asynchronous operations still running after the job has failed with the timeout. So this can be used, but you need to be aware of the consequences.

[GeoffreyPlitt]

Right, those executions themselves cannot be stopped (without sandboxed workers, etc) but it's nice that the queueing system will make the job eligible to be started again. In an idempotent/at-least-once-delivery situation, you want the job to be retried. If you look at how SQS works, there is always a timeout.

[manast]

I know SQS, but it is not really a timeout, it is a processing time window that can be extended actually (https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html#changing-message-visibility-timeout). You can get the exact same behavior with BullMQ if you process your jobs manually instead of using the facilities provided by the Worker class: https://docs.bullmq.io/patterns/manually-fetching-jobs