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.