Nested TRANSIENT providers not isolated in STATIC context when multiple DEFAULT parents inject same chain

[mag123c]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

When multiple DEFAULT scoped providers inject the same TRANSIENT → TRANSIENT chain, the nested TRANSIENT instances are shared instead of being isolated.

TestController (DEFAULT) → TransientLogger [1] → NestedTransientService [1]
TestService (DEFAULT) → TransientLogger [2] → NestedTransientService [1] ← Reused!

Each TransientLogger should receive its own NestedTransientService instance, but they share the same instance.

The root cause is the contextId !== STATIC_CONTEXT condition in getEffectiveInquirer()

// packages/core/injector/injector.ts:977-988
private getEffectiveInquirer(...) {
  return dependency?.isTransient &&
    inquirer?.isTransient &&
    parentInquirer &&
    contextId !== STATIC_CONTEXT  // ← This excludes STATIC context
    ? parentInquirer
    : inquirer;
}

Minimum reproduction code

https://github.com/stineslenea/logger-transient-example

Steps to reproduce

1. Clone https://github.com/stineslenea/logger-transient-example
2. Update @nestjs/* packages to 11.1.12
3. Remove line 12 in src/test.service.ts: @Inject(REQUEST) private readonly request: any,
4. Run npm start
5. Call GET /test
6. Check logs: NestedTransientService instance is shared between Controller and Service

Expected behavior

Each TransientLogger should receive its own NestedTransientService instance

TestController (DEFAULT) → TransientLogger [1] → NestedTransientService [1]
TestService (DEFAULT) → TransientLogger [2] → NestedTransientService [2] ← Expected

NestJS version

11.1.12

Packages versions

{
  "@nestjs/common": "11.1.12",
  "@nestjs/core": "11.1.12",
  "@nestjs/platform-express": "11.1.12"
}

Node.js version

22.x

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

Related Issues/PRs

• Bug: nested transient scoped service instance is being reused within request context #15689: Same issue in REQUEST context (Fixed by fix(core): ensure nested transient provider isolation #15815)
• A transient service uses another transient service #16097: TRANSIENT instantiation in STATIC context (Fixed by PR fix(core): instantiate nested transient providers in static context #16098)

This is the missing piece. TRANSIENT isolation in STATIC context.

The fix in #15815 explicitly excludes STATIC context with contextId !== STATIC_CONTEXT.
This condition needs to be revisited to also handle STATIC context isolation.

[mag123c]

I tried to solve it simply like #16258, but loadInstance seems much more complicated than I thought. 😢
I'll track it down more.

[mag123c]

The transientMap uses inquirerId (which is wrapper.id) as the key. But wrapper.id is per class, not per instance. So when multiple TRANSIENT parents inject the same nested TRANSIENT, they all get the same instance because they use the same key.

In REQUEST scope, this works because contextId is different for each request. But in STATIC context, contextId is always STATIC_CONTEXT (a constant), so there's no way to differentiate.

This seems to require changes to how transientMap keys work in STATIC context.