Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access job data or name in QueueEvents #1434

Closed
abustya opened this issue Sep 21, 2022 · 1 comment
Closed

Access job data or name in QueueEvents #1434

abustya opened this issue Sep 21, 2022 · 1 comment

Comments

@abustya
Copy link

abustya commented Sep 21, 2022

Hello,

I need to "broadcast" an event on job completion/failure, and I need to access an attribute associated with the job in the listeners.

I am planning to use QueueEvents for this, because as I understand, they are received by all the listeners, not just a single one (like a job).
My problem is, that the QueueEventsListener methods only receive the jobId.

So as I see my current options are:

  • Encode my custom job attribute into the return value at completion and into the failedReason at failure.
  • Encode the attribute into the jobId (encompanied by a random value, because the attribute is not unique).
  • Get the full job from the queue in the listeners. This could be a good option, but in this case I cannot use the 'removeOnCompletion' option, because the job would't exist anymore in the completion listener.
  • Store the jobId -> myattriibute map somewhere separately from bullMQ.
  • Use job.updateProgress({ myattribute, event: 'complete/failed' }) before completion & failure, and listen for this instead.

As I see, all of them can work, but none of them are really nice.

The feature I would prefer is:

  • access the job data in the QueueEventsListener or
  • access the job name in the QueueEventsListener

Or is there some other option I am overlooking?

Thank you!

@manast
Copy link
Contributor

manast commented Sep 21, 2022

We try to send as little data as possible in the events as this has an impact on performance.
If with broadcast you mean that the event should be sent to many receivers, you could try to use the updateProgress method inside the job processor, and send arbitrary data in it that your listeners could receive listening to the "progress" event in the Queue: https://api.docs.bullmq.io/interfaces/QueueListener.html#progress

@taskforcesh taskforcesh locked and limited conversation to collaborators Sep 21, 2022
@manast manast converted this issue into discussion #1435 Sep 21, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants