When is resolved the Queue.process promise ?

[Zikoel]

Hi, this is a question:

Is not clear for me when the returned promise from Queue.process is resolved, the process function is well documented but is not clear how to manage the process function return itself. If I write something like that:

queue.process('name', async job => {
    // Do the job
    }
).then( () => {
    console.log('processor added')
}

I don't event see the console log output!

[manast]

in theory when the queue is closed.

[dprentis]

Could the method be synchronous or resolve directly?

Reason I'm asking is, typescript-eslint doesn't like ignoring the returned promise: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-floating-promises.md

(Although, as a workaround, it's simple to just disable the rule in place)

[Zikoel]

Return synchronously is not a real solution maybe under the hood there is a reason for the Promise. I think you can manage the promise like my example (don't wait for it) and just don't expect to see the debug! If that sounds to you like an hack maybe we can ask another version (sync) of the process method... if is it possible! Something like processSync

[dprentis]

I guess it's really a question of API design. Currently running process actually does two things - it sets the handler and then starts processing the queue.

It might be more intuitive to separate that eg. specify the handler in the Queue constructor (or in a separate method), and have process without parameters just start the processing.

Currently, attaching a 'then' or 'catch' to the call to process isn't that useful - I might as well just call process as if it were synchronous (but then typescript-eslint complains, so I have to disable it) eg.

// eslint-disable-next-line @typescript-eslint/no-floating-promises
queue.process('name', async job => {
    // Do the job
    }
)

[kbarendrecht]

This caught me by surprise aswell, it wasn't really clear to me that .process() starts processing as well as adding a processor. I started out by awaiting the .process() method because i didn't want the queue to start before i added a processor.

It would make it easier to grok when there are seperate methods, something like; .setProcessor(..), startProcessing(..)

[manast]

yes. there are plans to improve the logic. In BullMQ for instance, the process is specified in the Worker constructor, so it is less confusing, however the processor starts processing directly after instantiating the worker, which is less code to type but more magic, which is not always good.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.