(Transaction?) Events not triggering subscriber when using forked EM with fresh event manager

[jcelmeta14]

Describe the bug
I am working on a feature on my app where I need do something immediately after a transaction starts and then do some clean up after it commits/rolls back.

To that end, I am adding a subscriber that I instantiate on a per-request basis. This subscriber needs access to the express request to do its thing, so when I am passing the request to it. I also want to clean-up the subscriber so that these events only trigger for this request.

So, I forked the EM and gave it a fresh event manager (so that the subscriber gets cleaned-up). When I do this, my subscriber does not trigger at all, even though I am using the forked EM to persist and flush. Interestingly even, if I do not provide a fresh event manager, the subscriber triggers, but instead the listener methods get triggered 2 times.

I have tried not forking the entity manager (does't the Mikro-orm middleware already give use request scoped entity managers?). The subscriber methods trigger, but new subscribers keep getting added every time a request comes in (I did not except this as I expected to get a fresh EM every request). I also think that the subscriber might trigger more times than excepted (instead of being called 1, the methods get called 2 times when not having a fresh event manager).

Stack trace
N/A

To Reproduce
Steps to reproduce the behavior:

1. Clone reproduction repo https://github.com/jcelmeta14/mikroorm-nestjs-reproduction
2. Install deps npm i
3. docker-compose up -d
4. Run test npm test -- app.controller.spec.ts
5. Comment out the forked em to see that the subscriber works when not forking.

Expected behavior
When forking EM and providing a fresh event manager, the subscribers need to trigger when using the forked EM.

Additional context
Add any other context about the problem here.

Versions

Dependency	Version
node	22.17.0
typescript	5.7.2
mikro-orm	6.6.0
your-driver	@mikro-orm/postgresql 6.6.0

[jcelmeta14]

It might also be the case that I am wrong about how the Entity manager and/or events are supposed to work. Maybe I need a different approach to achieve what I want (doing some prep work immediately after a transaction runs, and some cleanup work after a transaction ends)?

Also, I tried reproducing the issue with NestJS (so purely in Mikro-orm + Postgres). I could not reproduce the issue there. So I am guessing there must be something wrong with how the NestJS integration is set up.

[B4nan]

Your problem is most likely the fact that you keep the useContext flag enabled:

https://github.com/jcelmeta14/mikroorm-nestjs-reproduction/blob/main/src/providers/em-with-listener.provider.ts#L15C32-L15C48

This is for context resolution with the RequestContext helper via middlewares, with global services in the DI container - the opposite of what you are trying to do with the nestjs request scopes. Try removing that option.

[B4nan]

Note that you still have the RequestContext middlewares set up, it's the default behaviour of the nest orm adapter (see https://github.com/mikro-orm/nestjs/blob/master/src/mikro-orm-core.module.ts#L262-L264), and you are not disabling that in the forRoot call. That would be another way to fix this (you should do it regardless if you want to use nest request scopes - which I would btw discourage, they will have perf penalty, bigger than the ALS used for RequestContext middleware, and you don't need those here, you can use ALS to keep a reference to the request object too).

[jcelmeta14]

If I use AsyncLocalStorage, how would I go about passing the express request to the subscriber? Should I use a middleware, and then store a reference to the request in AsyncLocalStorage, and then retrieve it in the Subscriber?

If I am using the RequestContext helper via middlewares (so not disabling it with registerRequestContext: false), I still get a fresh instance of the entity manager per request, right?

Thank you for helping me with this!

[B4nan]

If I use AsyncLocalStorage, how would I go about passing the express request to the subscriber? Should I use a middleware, and then store a reference to the request in AsyncLocalStorage, and then retrieve it in the Subscriber?

You wouldn't pass it to the subscriber, you would read it from the ALS in the event handler. And yes, you'd set it up via a middleware.

I still get a fresh instance of the entity manager per request, right?

Yes, a clean EM fork, that's what the middleware does for you, and the global EM (and repositories) in nest DI would use it automatically (see https://mikro-orm.io/docs/identity-map#how-does-requestcontext-helper-work).

[jcelmeta14]

Awesome! Thank you for helping me out with this.

I decided to use nest-cls as it is a wrapper around ALS and has some tid-bits that make it nicer to use.