Support nested execution contexts and contexts created in a separate async execution within the same stack

[enisdenjo]

Closes #2227

Often found behaviour, especially when using @envelop/graphql-modules:

1. Create the operation controller in one plugin hook and use its context in another hook (different async execution, but same stack; for ex. onContextBuilding creates, onExecute uses)
2. Create the operation controller and use its context in a nested async execution
3. Create nested operation controllers. If the user does invokes createOperationController, they are creating a nested context since the plugin itself [already created an operation controller]](https://github.com/n1ru4l/envelop/blob/main/packages/plugins/graphql-modules/src/index.ts#L19C1-L22)

Note that creating an operation controller creates an execution context.

The current implementation of execution context handler has 2 work modes: using AsyncLocalStorage.enterWith (Node v14+) or async_hooks.createHook (fallback).

When using AsyncLocalStorage.enterWith, 1. and 2. will work because it binds to the stack. However, 3. will create wonky behaviour (probably related to nodejs/node#45848 and nodejs/help#3041). Node doesn't recommend using AsyncLocalStorage.enterWith because if its "magical" behaviour, reduced visibility and harder debugging (see comments from the related issues above). Additionally, even though AsyncLocalStorage.enterWith was introduced with Node v14, it's still considered unstable and Node's team doesn't want to promote it to stable because of the aforementioned reasons (see nodejs/node#35286). AsyncLocalStorage was introduced in #2395.

On the other hand, when using async_hooks.createHook, both 1., 2. and 3. will fail. Where 1. and 2. is much more important (because of @envelop/graphql-modules). The reason it fails is because of how the createHook's init is implemented - it only considers nested async executions, not parallel ones within the same stack.

TODO

• Should nested operation controllers even be allowed?

[changeset-bot]

⚠️ No Changeset found

Latest commit: 9dee25b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

💻 Website Preview

The latest changes are available as preview in: https://74339b92.graphql-modules.pages.dev

[darkbasic]

If the user does invokes createOperationController, they are creating a nested context since the plugin itself already created an operation controller

It's the other way around: in the context building function you manually create the operation controller before @envelop/graphql-modules has a chance to create its own. If it was the other way around the user wouldn't have to invoke createOperationController to access the injector from the context building function. I don't like having to manually create an operation controller so it would be nice if @envelop/graphql-modules could be hooked up before the context creation, for example by wrapping the context creation function.

As annoying as it may be this is unfortunately not the culprit of the issue leading to Cannot read properties of undefined (reading 'getModuleContext'), which is due to the async context getting lost when using AsyncLocalStorage.enterWith.
Since it works with Apollo I guessed it must be something in yoga/envelop which ends up losing the async context and that's why I suggested the problem might be outside graphql-modules (unless we decide to part with enterWith).