CLS context is not active

[cssArchitect]

Hello again, @Papooch

As we recently discussed an approach for manual GraphQL mounting, I started implementing my own guard for that (I use global guard). I have a strange issue with a context not being active after the first request.

In my guard, I have something like this:

 async canActivate(context: ExecutionContext) {
    const cls = ClsServiceManager.getClsService();
    // some logic
    cls.enterWith({});
    console.log('isActive', cls.isActive()) // true
    cls.set('someProperty', {key: "value"});
    return true;
 }

Then, down the callback chain I have a service that needed that someProperty.
So, I use:

const cls = ClsServiceManager.getClsService();
console.log('isActive', cls.isActive()) // false, after the first request
if (cls.isActive()) {
  const value = cls.get('someProperty')
}

Am I doing something wrong? I thought that a context would be unique for each request.

[Papooch]

What do you mean by context not being active after first request? Could you provide a minimal reproduction? I don't think I'll be able to help you without one.

[Papooch]

Thank for the reproduction. I see, so the context is not active in a guard that is mounted after the ClsGuard. Is it also not active in the controller or anything that happens after? I'll take a closer look and try to investigate.

[cssArchitect]

Thanks. It is also not active for the rest services as well.

[cssArchitect]

I've also read ASL docs, and I thought maybe its because, underlying this library, you only create one instance of AsyncLocalStorage and don't use disable method. But as far as I tried to do it with native implementation I faced the same result.

[Papooch]

I was able to reporoduce it on latest version of Nest. When I use the ClsGuard from nestjs-cls, it does not suffer from the same issue (due to not awaiting anything before entering).

That said, the .enterWith method is still experimental, so bugs like these are not that surprising. Therefore I am afraid that I can't fix this in the library.

As you also discovered, the fix is to run it synchronously, so I would propose changing the logic in the guard so that any awaited calls are executed only after cls.enterWith is called. The function can still be marked async, because Node runs all code within an async function synchronously, until the first await.

If you want to be sure, create the promise explicitly yourself without marking the method as async like so:

  canActivate(context: ExecutionContext) {
    const cls = ClsServiceManager.getClsService();

    cls.enterWith({});
    cls.set('someProperty', true);

    return new Promise<boolean>(async (resolve) => {
      await // logic
      resolve(true);
    });
  }

If the decision to enter the CLS context is dependant on an asynchronous task, then you're probably out of luck.

I don't completely understand why you're trying to do this, however, I would still advise you to not try to enable the CLS context conditionally. There's not much to gain from it, only suffering while debugging it later. You can conditionally populate it depending on the route, which should be enough and doesn't require custom brittle code.

[cssArchitect]

Thanks for your investigation. To sum up, context is not active only when it's initialized after asynchronous operation, not because the function is async. Maybe you should warn somewhere in your docs about this case.

I've also played a little with AsyncLocalStorage API and can confirm the same behavior. However, when I use disable method in the OtherGuard after I no longer need ASL store anymore, even when the context was initialized after an async operation with the enterWith method, I'm able to get it. You can find that interesting behavior here

[cssArchitect]

#133 (reply in thread)

And what are your thoughts on this? Does the AsyncLocalStorage singleton automatically clean its storage context in this library implementation? Because as stated in Node.js documentation:

Each instance of AsyncLocalStorage maintains an independent storage context. Multiple instances can safely exist simultaneously without risk of interfering with each other's data.

As I saw, Nest reuses the same class for each request.

[Papooch]

The problem with disable is that in the general case, you'd want to disable the CLS after the request has ended, which is impossible to detect with a guard. Other enhancers use the safer AsyncLocalStorage#run method, which enables CLS only for the duration of the callback.

Maybe you should warn somewhere in your docs about this case
I specifically warn that using the enterWith method is not stable, but I guess I can also link this thread for more context.

That said, if you need a very specific behavior, it's probably better to create a custom solution with raw AsyncLocalStorage, than trying to bend the nestjs-cls library to fit your very specific needs.

[Papooch]

Does the AsyncLocalStorage singleton automatically clean its storage context in this library implementation

What do you mean by automatically cleaning the storage? There's only one instance of ALS and the contents of each context-bound store are deleted by the garbage collector after all taks spawned from an active context have finished. One AsyncLocalStorage is in charge of managing different stores per context - it does not share state across all requests.

Earlier versions of this library supported creating multiple AsyncLocalStorages (called namespaces), but that feature has been removed for the lack of interest and unnecessary complexity (but it can be still brought back manually).

The core idea of nestjs-cls is that it gives you single shared storage across the duration of a request. You can also create sub-contexts by nesting the cls.run calls. If there are any other use cases of AsyncLocalStorage, that this library doesn't support, then those can be either created as plugins or implemented independently.