I use the bull library to set up a processing queue, and when I use the process
method for an existing queue I get a warning since this method returns a promise. I noticed bull's documentation ignores this return value and I want to know if it's safe to ignore such promise.
Other small questions, what can I expect if this function fails? If I need to await for it to finish, this leads to issues since I would have to await the result everywhere, is there a way to prevent this?
In https://github.com/OptimalBits/bull/issues/1688 (April 2020), committer manast answers Zikoel's question "Is not clear for me when the returned promise from
Queue.process
is resolved" with "in theory when the queue is closed." Becauseprocess
starts the queue, as dprentis notes, the promise represents the status of the queue itself. The question has active team engagement from last week, so it is likely accurate to the maintainers' current understanding or intent.For convenience, here's a link to the Queue.process documentation. You're right that it does not demonstrate or acknowledge the return
Promise
from calls toprocess
, despite being very careful to prescribe the Promise return requirements of theprocessor
function to be passed in.From a cursory look at the code (Queue.run), it seems that
process
specifically resolves when the closure of the queue resolves the promises (number set byconcurrency
, default1
) created as part of that single call toprocess
. However, tests seem mostly to ignore the returned Promise or use it to chaincatch
to signal test completion; the few examples that use the returned promise seem to be suppressed or otherwise exceptional. Because that behavior appears to be officially undocumented and untested, you might not want to rely on it heavily.Though it appears that it would not be a problem to ignore the returned Promises (as in the documentation and tests) or
await
any one of them to passively detect queue closure, you might also hedge your bets by collecting all of the returned promises into aPromise.all
call and chainingcatch
to log any errors.