Scoped service breaks injection

[Minishlink]

Bug Report

Current behavior

Hello, on Nest v8, when using a service S that is scoped, it breaks injection of the service B that uses this scoped service S in upper services (eg. A) in the dependency tree (please look at the CodeSandbox below), when the service A is used in a guard that is used for a controller route or graphql query. This used to work well in Nest v7.
There are no error messages shown at startup, but when a request or a graphql query is made, this results in an error where B is undefined.

This problem might be linked to the new way of resolving injectables (by reference rather than a string description) in Nest v8. I also saw a problem with @Inject(forwardRef that used to work on v7 FYI, although I didn't do a PR at the time, but it may be linked.

Input Code

https://codesandbox.io/s/flamboyant-poitras-0kbbe?file=/src/modules/User/scoped.ts

If you go to /content, you'll have an error. Then, when you edit /src/modules/User/scoped.ts by removing the scope, after reload, when you go to /content, you'll see a "ok".

Expected behavior

B should be defined

Possible Solution

Avoid using scoped services for now

Environment

Nest version: 8.0.6 (also 7.6.17)
 
For Tooling issues:
- Node version: 14
- Platform:  Linux

[Minishlink]

May be linked to #4873 or #5778 but I honestly don't know

[Minishlink]

Looks like I reproduce also on Nest v7, my initial assumption was wrong.

[jmcdo29]

Seems like it might be related to this

[kamilmysliwiec]

Similar issue:
#5778 (comment)

To fix your issue, change:

@Injectable()
export class Guard {...}

to:

@Injectable({ scope: Scope.REQUEST })
export class Guard {...}

Result:

Normally, we'd infer the provider's scope implicitly but since you have several circular dependencies in your project, we simply don't have sufficient metadata to properly determine all scopes. Circular dependencies are considered a bad practice and they should never be used unless absolutely necessary (and that's why we provided helpers like forwardRef, to cover these edge-case scenarios), especially when used in combination with scoped-providers (scoped providers due to their nature should never have circular dependencies OR be defined within modules that have circular imports).

I'd personally strongly advise eliminating all circular dependencies in your project. There's not much we can do on the framework's side.