Implicit request-scope propagation into default-scoped NestJS controllers

Direct Answers

1. Yes. Scope bubbling follows the dependency-injection graph, not module boundaries. A DEFAULT-scoped controller that injects a REQUEST-scoped provider — directly or transitively — becomes REQUEST-scoped at container resolution time, even if the provider comes from an imported module.
2. Condition: Any provider in the controller's transitive dependency closure is declared @Injectable({ scope: Scope.REQUEST }). The DI container resolves scopes at bootstrap by walking the graph; the strictest scope in a chain wins.
3. Crossing boundaries: Bubbling crosses module boundaries whenever an importing module's provider or controller depends (directly or indirectly) on an exported REQUEST-scoped provider. The exporting module's internal scopes are unaffected; only the importer's resolution graph changes.

Mechanism (Confirmed in NestJS v10+)

The injector builds a scope resolution graph during InstanceLoader bootstrap. In resolveScope() (see @nestjs/core/injector/container.ts), each provider's effective scope is the maximum of its declared scope and the scopes of all its dependencies. Module exports merely expose providers; they do not create scope firewalls.

When a Default Controller Is Recreated Per Request

• It injects a REQUEST-scoped service directly.
• It injects a DEFAULT-scoped service that itself injects a REQUEST-scoped service (transitive).
• The REQUEST-scoped provider originates in any imported module and is reachable through the import/export graph.

All of the above cause the controller's entire dependency subtree to be instantiated per request, increasing GC pressure under high throughput.

Confinement Strategies

1. Explicit annotation: Mark controllers that should be request-scoped with @Controller({ scope: Scope.REQUEST }). Makes intent visible and prevents silent bubbling elsewhere.
2. Factory providers: Export a DEFAULT-scoped factory (useFactory) that resolves the REQUEST-scoped instance lazily per invocation, breaking the transitive chain.
3. Graph segregation: Restructure so REQUEST-scoped providers are injected only into other REQUEST-scoped consumers. Keep DEFAULT-scoped services free of REQUEST dependencies.
4. Context-aware providers: For GraphQL/microservices, the same rules apply; the "request" lifecycle is defined by the context creator (HTTP interceptor, GraphQL context, message handler).

Verification Steps

1. Create two modules: ModuleA exports a REQUEST-scoped service; ModuleB imports ModuleA and has a DEFAULT-scoped controller injecting that service.
2. Log constructor calls with a request ID (e.g., via REQUEST injection or cls-hooked).
3. Send multiple requests; observe per-request instantiation of ModuleB's controller.
4. Enable DEBUG=nestjs:* at startup to see scope resolution logs.

Assumption: NestJS v10+. Behavior is stable but undocumented as a guarantee; treat as implementation detail subject to change.