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." Because process 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 to process, despite being very careful to prescribe the Promise return requirements of the processor 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 by concurrency, default 1) created as part of that single call to process. However, tests seem mostly to ignore the returned Promise or use it to chain catch 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 a Promise.all call and chaining catch to log any errors.
