Replies: 1 comment 2 replies
-
Did you manage to solve the problem? |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I use NestJS-GraphQL-MikroORM frameworks to build my backend and I have problem using graphql subscriptions (graphql-ws based). I do not find the point where and how the proper context initialization should be done.
I have a scheduled task (with @UseRequestContext() decorator as described in documentation) where I build a list of entities and I publish them. Until this point everything seems to be fine.
The problem comes when these entities have properties which are resolved later by @ResolveField decorators. Resolving these properties generates further ORM queries, but they are already out of that scope. They try to use the global entity manager which fails by design.
I did not find such entry point like express middlewares to perform the context initialization. It is just a simple context() function call where I can add extra data to the context, but the scope goes away when I return, so the AsyncLocalStorage based RequestContext cannot be used here.
How can keep my entity repositories operational in this case? I do not want to check (and fork if necessary) the entity manager in every ORM request.
Beta Was this translation helpful? Give feedback.
All reactions