Regression: Tenant connection mix-up after upgrading from 2.5.1 to 2.6.0

[KamalAman]

I’m using a tenant-per-database setup and durable providers for TENANT_KYSELY_CONNECTION.

After upgrading @nestjs-cls/transactional from 2.5.1 to 2.6.0, I noticed an issue:
When making requests in the following sequence — Tenant A → Tenant B → Tenant A —
the second request for Tenant A incorrectly returns Tenant B’s connection (and data) 😅

Here’s the comparison between the versions:
@nestjs-cls/transactional@2.5.1...@nestjs-cls/transactional@2.6.0

I’ll try to create a reproducible example soon, but I’m not doing anything unusual.
Downgrading back to 2.5.1 resolves the issue.

A sample outline of the module. Everything in the registry is correct, it just the front txHost connection a service that uses it.

@Global()
@Module({
  imports: [ClsModule],
  providers: [TenantKyselyRegistry],
  exports: [TenantKyselyRegistry],
})
export class TenantKyselyModule {
  public static register(): DynamicModule {
    return {
      module: TenantKyselyModule,
      imports: [
        RequestConnectionModule,
        VaultModule,
        ConfigModule,
        ClsModule.forRoot({
          plugins: [
            new ClsPluginTransactional({
              imports: [],
              adapter: new TransactionalAdapterKysely({
                kyselyInstanceToken: TENANT_KYSELY_CONNECTION,
              }),
            }),
          ],
        }),
      ],
      providers: [
        {
          provide: TENANT_KYSELY_CONNECTION,
          scope: Scope.REQUEST,
          durable: true,
          inject: [
            REQUEST,
            TenantKyselyRegistry,
            ConfigService,
          ],
          useFactory: (  request) => {
              const tenantId = request.headers['tenant-id']
               const { db } = registry.getOrCreate(tenantId, { database: tenantId , ....});
               return db;
           },
        },
      ],
      exports: [TENANT_KYSELY_CONNECTION],
    };
  }
}

@Injectable()
export class TenantKyselyRegistry implements OnApplicationShutdown {
  private readonly registry = new Map<string, PoolEntry>();
  private readonly logger = new Logger('TenantKyselyRegistry');

  getOrCreate(tenantId: string, poolConfig: PoolConfig): PoolEntry {
    const key = `${tenantId}`;
    const existing = this.registry.get(key);
    if (existing) return existing;

    const pool = new Pool(poolConfig);
    const db = new Kysely<unknown>({
      dialect: new PostgresDialect({ pool }),
    });
    const entry = { pool, db } as const;
    this.registry.set(key, entry);
    return entry;
  }

  async onApplicationShutdown() {
    const entries = Array.from(this.registry.values());
    await Promise.allSettled(entries.map((e) => e.pool.end()));
    this.registry.clear();
  }
}

[Papooch]

Thanks for the report - I think I see the problem.

The issue most likely happens because you're mixing request-scoped providers with Proxy providers.

Before, the TransactionHost was injected into the target class, and because it depended on a request-scoped provider, it was re-created on every request.

The aim of nestjs-cls is to eliminate the need for re-creating whole dependency trees and insted storing the request-scoped data in the CLS context. The library uses Proxy providers, which are essentially singletons (in Nest's sense of the word) that only proxy access to the underlying "request-scoped" instance.

Injecting actual REQUEST-scoped dependencies into a Proxy completely eliminates all benefits, because now you you're re-creating the Proxy itself on each request and weird things may happen (I never intended to support this use-case).

Injecting a Proxy into a REQUEST-scoped dependency is fine (in terms of functionality), but the intention is questionable.

---

To fix your issue, try turning your TENANT_KYSELY_CONNECTION into a Proxy provider.

imports: [
  RequestConnectionModule,
    VaultModule,
    ConfigModule,
    ClsModule.forRoot({
      plugins: [
        new ClsPluginTransactional({
          imports: [],
          adapter: new TransactionalAdapterKysely({
            kyselyInstanceToken: TENANT_KYSELY_CONNECTION,
          }),
        }),
      ],
    }),
    ClsModule.forFeatureAsync({
      provide: TENANT_KYSELY_CONNECTION,
      // CLS_REQ is a Proxy version of REQUEST
      // It is only available if you use middleware to setup CLS.
      // Otherwise you need to use CLS_CTX, which is a Proxy of ExectutionContext
      inject: [CLS_REQ, TenantKyselyRegistry].
      useFactory: (request: Request, registry: TenantKyselyRegistry) => {
        const tenantId = request.headers['tenant-id']
        const { db } = registry.getOrCreate(tenantId, { database: tenantId , ....});
        return db;
      }
    })
  ],

---

There is a sligt downside that Proxy providers don't natively support the "durable" part, but this limitation can be easily overcome by using a custom cache - which as I notice you already do using the TenantKyselyRegistry. Other than that, a Proxy provider doesn't cause the dependency tree to be recreated on every request, so there's really little need for a "durable" version.

All in all, there should be a warning in the docs about mixing actual REQUEST-scoped providers with Proxies.

---

If it doesn't help, please try to provide the reproduction, so I can investigate on my end,

[KamalAman]

This worked, thank you!!

Now, let me get something straight. Are you saying that other layers such as resolvers/services/xxx wouldn't actually don't have to be request scoped anymore when using proxy providers?
But then, those wont be durable unless I manually manages them cache?

Also, is there a way to just Inject CLS into the proxy factory rather than having to parse out the Context. I already have a new TenantIdInterceptor(app.get(ClsService)) setup. It would be nice to just reuse the tenantId from that.

Here is my updated reference code that works

 ClsModule.forFeatureAsync({
      global: true,
      provide: TENANT_KYSELY_CONNECTION,
      inject: [CLS_CTX, KyselyDatabaseConnectionService],
      useFactory: async (clsContext: ExecutionContext, dbService: KyselyDatabaseConnectionService<KyselyDatabase>) => {
        const connection = await dbService.getTenantConnection(clsContext);
        return connection;
      },
    }),
    ClsModule.forRoot({
      global: true,
      middleware: {
        mount: true,
        resolveProxyProviders: false,
      },
      interceptor: {
        mount: true,
        saveCtx: true,
        resolveProxyProviders: true,
      },
      guard: { mount: true, generateId: true },
      plugins: [
        new ClsPluginTransactional({
          imports: [],
          adapter: new TransactionalAdapterKysely({
            kyselyInstanceToken: TENANT_KYSELY_CONNECTION,
          }),
          enableTransactionProxy: true,
        }),
      ],
    }),

[Papooch]

Now, let me get something straight. Are you saying that other layers such as resolvers/services/xxx wouldn't actually don't have to be request scoped anymore when using proxy providers?

Yes, exactly. The only requirement is that you don't use them in the constructors because there wouldn't be any request-related instance behind them.

But then, those wont be durable unless I manually manages them cache?

Yes. I had plans to implement the "durable" logic, but I haven't got around to doing it, since the caching layer is so simple to create manually.

Also, is there a way to just Inject CLS into the proxy factory rather than having to parse out the Context.

Yes, it behaves like a regular provider, only it's re-created for every request to populate the proxy's target for the duration of the request.

You can inject ClsService, as you would normally, and use cls.get('tenantId') to get the contextual tenant connection.