Skip to content
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

Bull events + Nestjs request scoped dependencies #1942

Open
1 task done
Treen11 opened this issue Dec 21, 2023 · 0 comments
Open
1 task done

Bull events + Nestjs request scoped dependencies #1942

Treen11 opened this issue Dec 21, 2023 · 0 comments
Labels

Comments

@Treen11
Copy link

Treen11 commented Dec 21, 2023

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

I am currently migrating a manual bull setup into nestjs using this library. Everything works great, except reacting on bull events in cases, where the implementation of the "event handler" requires some request-scoped dependencies.

In my case for example, i am using MikroOrm and i want to create a new request-scoped instance for each request / job handling / bull event reaction. If i understand it correctly, for a processor, the request-scope actually means a "job-scope". So what i think is the issue in this case, is that there is no "request" (job) when reacting to a bull event and therefore request-scoped processor cannot be used to handle bull events.

Currently, if i want to create a new instance of the entity manager for each bull event and use it in all of the classes that are involved in the event handling, the only option i see is to bypass the DI system and instantiate everything on my own.

My two main questions are:

  • does the proposed solution below make sense?
  • is there any other already existing way to solve my problem? Eg use a fresh instance of the MikroOrm entity manager scoped to the entire event handling using the DI?

Describe the solution you'd like

I would like any bull event to create a new "request" context so that i can use the DI system just as with http controllers and bull job processing.

Teachability, documentation, adoption, migration strategy

No response

What is the motivation / use case for changing the behavior?

See the problem description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant