Injecting request scoped provider in middleware result in double provider creation and cannot access request by injection

[fredericbarthelet]

Bug Report

Current behavior

Injecting request scoped provider in middleware result in the following unwanted behavior :

• a first instance of the provider is injected in the middleware. This provider, despite being request scoped, cannot access request by using @Inject(REQUEST)
• a second instance of the provider is created for route handling. This second instance can access request.

Input Code

In order to test this, I created a repo : https://github.com/fredericbarthelet/nestjs-bug-middleware

In this repo, there is a single controller, a single service and a single middleware.
The service is both injected within the middleware and the controller.
In the service constructor, the following lines allows tracking of service creation and availability of request object :

constructor (@Inject(REQUEST) private readonly request: Request) {
    this._id = parseInt(Math.round(Math.random()*1000000).toString());
    if (request) {
      console.log('Request is defined in AppSerive instance '+this._id);
    } else {
      console.log('Request is not defined in AppSerive instance '+this._id);
    }
  }

The resulting output when requesting the / route :

Request is not defined in AppService instance 92458
Middleware execution
Request is defined in AppService instance 742177

Expected behavior

I was expecting a single occurence of AppService.
I was expecting AppService to be able to access request via injection (to avoid passing request object as a parameter of the method)

Possible Solution

I found related issues that are close to my problem, but not directly talking about request availability in subsequent request scoped services : #2648 and #1916
No idea how to fix it.

Environment

Nest version: 6.5.3
 
For Tooling issues:
- Node version: 10.15.3
- Platform:  Mac

[fredericbarthelet]

Works perfectly now, thanks @kamilmysliwiec :)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.