Request-scoped providers causing Singleton recreation in NestJS DI

Goal: Determine if a Singleton provider that depends on a Request-scoped provider is instantiated once per application lifecycle or recreated for each incoming request, and assess the associated DI tree reconstruction overhead in high‑throughput NestJS applications.

Constraint: The NestJS documentation states that injecting a Request-scoped provider into a Singleton promotes the Singleton to Request scope, but it does not quantify the performance impact of repeatedly rebuilding the dependency sub‑tree for each request, especially when deep dependency chains are involved.

• Does the DI container actually create a new instance of the Singleton for every request when it has a Request-scoped dependency, or does it retain a single instance and merely request‑scope the dependent provider?
• What measurable latency or garbage‑collection pressure is introduced by reconstructing the DI tree per request in a scenario with a Request-scoped provider nested three levels deep?
• Are there configuration options or alternative patterns (e.g., using ModuleRef for dynamic resolution) that can mitigate this overhead without losing request‑scoped semantics?