Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DI doesn't inject a scoped request provider using @Inject and Symbol #9352

Closed
3 of 15 tasks
BrendonMFO opened this issue Mar 18, 2022 · 4 comments
Closed
3 of 15 tasks
Labels
needs triage This issue has not been looked into

Comments

@BrendonMFO
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

The DI isn't injecting/resolving a provider through @Inject when the property is a Symbol

This doesn't work:

@Injectable()
class TestTargetService {
  @Inject() // Scoped Request
  private readonly testService: TestService;

  @Inject(SYMBOL_INJECTOR) // Scoped Request
  private readonly [SYMBOL_SERVICE]: SymbolService;

  getTestService() {
    return this.testService;
  }

  getSymbolService() {
    return this[SYMBOL_SERVICE]; // undefined
  }
}

But injecting those same providers through the constructor, the DI resolves all providers perfectly

This does work:

@Injectable()
class TestTargetService {
  @Inject(SYMBOL_INJECTOR)
  private readonly [SYMBOL_SERVICE]: SymbolService;

  constructor(private readonly testService: TestService) {}

  getTestService() {
    return this.testService;
  }

  getSymbolService() {
    return this[SYMBOL_SERVICE]; // Symbol Service Instance
  }
}

I've spent a time debugging and found something about the cache of the metadatas. The property's instance wrapper was a new property but it was supposed to be an element inside the array, increasing its length. Was it supposed to be added as a new property?

bug_detail

Minimum reproduction code

https://github.com/BrendonMFO/nestjs-injection-bug

Steps to reproduce

  1. npm i
  2. npm test

There're two test files each one using a different way to inject the providers

Expected behavior

The DI should be able to resolve the dependencies through constructor and the decorator

Package

  • I don't know. Or some 3rd-party package
  • @nestjs/common
  • @nestjs/core
  • @nestjs/microservices
  • @nestjs/platform-express
  • @nestjs/platform-fastify
  • @nestjs/platform-socket.io
  • @nestjs/platform-ws
  • @nestjs/testing
  • @nestjs/websockets
  • Other (see below)

Other package

No response

NestJS version

8.4.1

Packages versions

"dependencies": {
  "@nestjs/common": "^8.0.0",
  "@nestjs/core": "^8.0.0",
  "@nestjs/platform-express": "^8.0.0",
  "reflect-metadata": "^0.1.13",
  "rimraf": "^3.0.2",
  "rxjs": "^7.2.0"
}

Node.js version

16.13.1

In which operating systems have you tested?

  • macOS
  • Windows
  • Linux

Other

No response

@BrendonMFO BrendonMFO added the needs triage This issue has not been looked into label Mar 18, 2022
@micalevisk
Copy link
Member

indeed. Here's a minimum reproduction of this: https://gitlab.com/micalevisk/nestjs-issue-9352

@micalevisk
Copy link
Member

micalevisk commented Mar 19, 2022

I was looking at the value on constructor. But this works (using the default scope):

const TokenSymbol = Symbol()
const A = Symbol('A')
const B = Symbol('B')

@Module({
  providers: [
    { provide: TokenSymbol, useValue: 'hello' },
    { provide: 'my-str-token', useValue: 'world' },
  ],
})
export class AppModule {
  @Inject(TokenSymbol) private readonly [A]: string
  @Inject('my-str-token') private readonly [B]: string

  onApplicationBootstrap() {
    console.table({ hello: this[A], world: this[B] })
  }
}
/*
┌─────────┬─────────┐
│ (index) │ Values  │
├─────────┼─────────┤
│  hello  │ 'hello' │
│  world  │ 'world' │
└─────────┴─────────┘
*/

Thus this should be a bug with the @Injectable({ scope: Scope.REQUEST }) + using symbol as a field name

@MyAeroCode
Copy link
Contributor

I have fixed what was causing this issue.
I'll submit a PR as soon as I'm done writing the test code 😃

@kamilmysliwiec
Copy link
Member

Let's track this here #9456

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs triage This issue has not been looked into
Projects
None yet
Development

No branches or pull requests

4 participants