Add a way to fail job without throwing error from processor
From the docs:
When a processor throws an exception, the worker will catch it and move the job to the failed set
In this way you can't separate exceptions and errors
For example i have a processor, that can:
- succeed and return value of type
T - generate an exception of type
Eand return it - throw uncaught error (for example error, that emerged in external library)
There's one way right now, how you can return exception from the processor to fail job — throw an error. This way you'll lose type of exception in failed event handler.
The reason why you want job to fail with exception is to decide to retry a job or not in failed event handler
If there was a way right now to retry a job from completed event handler you could return either monad from processor — container with either value or exception. But now you can't do that
+1 I use BullMQ for requests with timeouts, and i want to handle timeout errors without exceptions, but retry request with Bull. It would be great, if you add some way to fail current job without throw error
When you throw an error you can write any message in the error as you want, why can't you use that to decide what to do in case of error?
This is a reason to have structured errors, though In my apps, I usually use boom since we can attach additional data.
It mentions the following the docs :
When a processor throws an exception that is considered unrecoverable, you should use the UnrecoverableError class. In this case, BullMQ will just move the job to the failed set without performing any retries overriding any attempts settings used when adding the job to the queue.
Would that support your use case, @nikolayemrikh?